Posts Tagged ‘chrome’

Google Chrome Built-in PDF Viewer Incompatibility with IFRAME and a Workaround

Saturday, December 11th, 2010

With the recent automatic upgrade of Google Chrome to version 8, Google made their built in PDF viewer the default viewer *.  I.e. there is now no need to separately download Adobe Reader or Adobe Flash Player to browse the web with Google Chrome.

Generally, I like this addition to Google Chrome; however, it caused some work for us.  Our web based bingo card generator, print-bingo.com, is highly dependent on PDF’s.  That’s the sole reason why our bingo cards are dead-easy to print out by the hundreds.  Unfortunately, Chrome’s built-in PDF renderer does not display PDFs that are in an IFRAME tag properly.

For the last few days, this is what users of print-bingo.com would see after generating 5 pages of bingo cards on print-bingo.com:

 

Broken PDF rendering in an IFRAME in Google Chrome 8 - screenshot from print-bingo.com

Broken PDF rendering in an IFRAME in Google Chrome 8 - screenshot from print-bingo.com

Chrome tries to scale the parent page to fit everything in… and it fails badly.

We were not able to get things working 100% the way we would like, but we have a workable situation now.

The basic steps that we had to take:

  • Change from IFRAME to OBJECT tag.  For whatever reason, this fixes the zooming issue.  And it was quite simple.  In our case, there wasn’t much difference between the two HTML tags.
  • Unfortunately, we can’t find a way to get Chrome to print the contents of the object tag without printing the rest of the page (though, perhaps using CSS  might work).
  • Instead, we added some bold warning text that gives Chrome users instructions to use the manual download links. We use a little function to identify Chrome users – the two key lines of code are: 
    $u_agent = $_SERVER[‘HTTP_USER_AGENT’]; 
    if(preg_match(‘/Chrome/i’,$u_agent)) { $ub = “Chrome”; }

So, we ended up with a workaround.  We sincerely hope that Google will add the missing interface elements that will make things just work, but until then, we are doing some other site improvements as we prepare to bump up the price of Premium Access to $12 in 2011.

* If you want to go back to using Adobe Reader in Google Chrome, you can turn off the  built-in viewer by going to the special address about:plugins and change Chrome PDF Viewer to Disable.  Of course, website owners should not depend on end-users to do this just to visit your site!

 

 

Tags:, , , , , , , , , ,
Posted in annoying, bingo cards, Google, html, print-bingo.com, printing, programming, web development | 1 Comment »

Print-Bingo.com Works with Google Chrome Web Browser (again)

Monday, July 5th, 2010

Today we updated print-bingo.com’s programming.

The biggest fix, is that our site now works properly in current versions of Google Chrome. Our web based system for generating highly printable bingo cards is great… but once in a while we run into compatibility issues. For now, it’s fixed. We’ve tested in current Firefox, Internet Explorer, Google Chrome, and Apple Safari web browsers. Ironically, part of the programming fix was related to a compatibility tweak for Mozilla browser from years back. Mozilla users, if you actually still exist, you will need to use a different browser to use print-bingo.com now.

At the same time, we made live a feature that we wrote for a custom bingo job a few months back. All bingo cards within a single run are now guaranteed to be unique. Previously, it was entirely random if a card was duplicated in a run – but it was highly, highly, unlikely. In fact, we programmed an email notification if the dupe-tester actually catches a dupe.

We had to hard-code a duplicate entry to actually make sure the dupe tester and the email notifier worked. The odds of duplicate cards that are randomly generated is extremely low – you can’t generalize exact odds, since every custom bingo card design is different.

The site has probably generated 1,000 card runs since the new code went live… and we haven’t been notified of a duplicate card yet. If we ever catch a dupe, we’ll be sure to post about it.

More code changes are on the way. It’s summer, traffic to print-bingo.com is lower than normal.

Tags:, , , , , , , , , , ,
Posted in annoying, bingo cards, web development | No Comments »

User Scripts Broken in Google Chrome?

Friday, December 11th, 2009

A little while ago my custom user script for Chrome stopped working. I’m currently using the “dev channel” at home. When I first switched to Chrome, that was the only version that supported user scripts (basically GreaseMonkey from FireFox integrated into Chrome).

My script is simple, it makes some font and color changes to a few websites that I view regularly to make them more legible (IMHO). I should bundle it into an extension some day…

Anyway, it took a bit of research to figure out what happened. Look here on the Google Chrome blog:

[r33013] Disable –enable-user-scripts. (Issue: 27520)
NOTE: You can now install user scripts by navigating to them. You will have to reinstall your current scripts (they aren’t migrated).

— http://googlechromereleases.blogspot.com/2009/12/dev-channel-has-been-updated-to-4.html

So, scripts are still supported, but I have to install it again. I didn’t quite understand “navigating to them” meant, but it actually means exactly what it says. In the address bar browse the file system, e.g. go to here:
C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\User Scripts

Then double click on your .JS file, and a little extension installation prompt pops up. It’s pretty cool actually.

Hmm… now that Google Chrome regular version supports extensions, I might be able to take myself off the dev channel.

Tags:, , , , , ,
Posted in software, tools, web browser | 1 Comment »

Cross Browser Compatibility of TEXTAREA and Chrome, Firefox, and IE with CSS “white-space: nowrap;”

Monday, October 19th, 2009

Today, the Perceptus Web Tools got a minor upgrade to improve browser compatibility.

A company bought a  license to our unique Excel to SQL INSERT Commands tool for their internal, confidential, use.  Cool! We never expected tools.perceptus.ca to be a revenue generator… but it does have unique features.  After all, we wrote them because we couldn’t find another website that could do the task for us!

In the interest of delivering a nice package to our new licensee, we  noticed that many of the text mangling features did not work in Google  Chrome.  Chrome web browser was stripping line breaks and consolidating sequential “spaces”.  We then realized that the site was not working in Internet Explorer either. Whoops.  Well, it is a  site primarily for our own internal uses, after all.

We had discovered a browser compatibility issue that probably affects very few people. We want a textarea without any wrapping, because some features are based on copy and pasting large amounts of data from Excel – automatic text wrapping makes hard to read.

Our original, Firefox functional, Chrome and Internet Explorer non-functional, TEXTAREA used the following:

  • CSS: white-space: nowrap;
  • TEXTAREA attribute: WRAP=”OFF”

In Firefox, we got a nice blob of text that you can scroll horizontally displayed.  In IE7 and IE8?  All kinds of crazy.  “Enter” keys got replaced by some sort of special inline character, lines and spaces got trimmed or cut out.  Google Chrome stripped out line breaks and leading spaces, and other oddities.

Upon research, we learned that the “WRAP” attribute is not W3C approved.  Technically, it is not deprecated, but that’s because it never existed in the specifications. So we removed it and tried to use only CSS. We tried a few combinations of the overflow, white-space, and display CSS properties.  They didn’t work.

What did work?

No CSS at all.

If you view the source of the tools.perceptus.ca site and the corresponding CSS file, you will only see this:

<TEXTAREA NAME=”thetext” ROWS=”20” COLS=”100” WRAP=”OFF“>

This works as we wanted in all three web browsers.  It is officially non-standard.  But it works.

If someone would like to submit a CSS that will actually work, I’d love to see it.  But for now, I’m just going to keep complaining about how much web programming still stinks. Maybe the moral of the story is that thanks to Apple’s Safari and Google Chrome, every web site should be tested against at least one of the Webkit based browsers in addition to Firefox and Internet Explorer.

Tags:, , , , , , , , , , , ,
Posted in annoying, programming, tools.perceptus.ca, web browser | 4 Comments »