How to detect FireFox4 or any updated versions of FireFox, to include specific stylesheet?
Note: FF4 and FF5 gives font-size too small when printed. on screen its fine(FF3.0 to FF5).
You need to inspect the user agent string. How you do that wil depend on what technique you wish to use and what platform you are on. In PHP you can inspect the value of $_SERVER['HTTP_USER_AGENT'], or you can do it using jQuery as Eamorr says. It is also possible a number of other ways, you'll have to tell us more about your setup.
Related
I am creating a pdf document (via ColdFusion), but when I preview the rendered pdf in Firefox, I get the number "4" where my checkmarks are supposed to be (see photo below). When I preview the exact same pdf in Chrome or IE, I see the checkmark, and it all works perfectly!
I am pre-populating the pdf form fields (via ColdFusion session variables), and then rendering the pdf using the following markup:
<cfpdfform source="82040.pdf" action="populate">
<cfpdfformparam name="org" value="">
</cfpdfform>
Here is the resulting pdf form in Internet Explorer:
Note how the checkmark is rendered properly:
Here is the same form previewed in FireFox:
Note how the the checkbox has a "4" instead of a checkmark:
Any help would be greatly appreciated!
It is a bug with Firefox's PDF Viewer. Currently, there is no fix. As radiovisual's post points out, the bug in the underlying library (pdf.js) was supposedly fixed. However, there is still the issue of Mozilla updating the older version baked into Firefox (which is what most folks are using). Currently, that bug is still outstanding.
Probably the best you can do is to return the pdf as an "attachment", rather than "inline", so the browser prompts them to "open/save" the file. If the user opts to "open" the pdf, it should open with their default program instead. (Adobe Reader is the default for most users).
<cfheader name="Content-Disposition" value="attachment; filename=fileName.pdf">
<cfcontent type="application/pdf" .../>
Update:
This bug was apparently addressed already, as pointed out via the project's github repo: the bug was supposedly fixed during this commit. So if you are still experiencing problems, it either means:
You are using an outdated version of the pdf.js library,
Or, the problem has been re-introduced into the library.
So to start things off, you will want to make sure that you are using the most up-to-date version of the pdf.js library. If you are still experiencing problems, even with the most up-to-date version, then the problem is still within the embedded pdf document viewer, and there aren't too many things you can do to fix this until the project maintainer's finally fix the problem.
The issue you are experiencing (the reason why you are seeing a "4" where there should be a checkmark, is because the pdf.js library is using a special symbol font to render the checkmarks, but in problematic versions of firefox's embedded pdf-viewer the symbol font isn't rendering the checkmark correctly, so it shows a "4" instead of a checkmark -- because the checkmark symbol they are using in the custom font just so happens to be mapped to the number "4".
Similarly, for the same reasons cited above, if you assign the checkbox to render squares (instead of checks), the letter "N" will appear in the checkbox instead of a square, because the square shape symbol is mapped to the letter "N".
This problem only exists in the embedded pdf document viewer in Firefox but will look perfectly normal when viewed in Adobe Acrobat Reader, or other offline pdf readers (and other browser pdf readers, which is why it looks fine in Chrome and IE), so when users download the form, it will appear like you would expect it to.
Some workarounds / optimizations you could try:
Try one of these, or all of these, they are in no particular order (or guaranteed to work)
Don't rely on the built-in pdf.js browser extension in firefox, instead, make your own updated version based on the latest pdf.js source or target another pdf library and use it's browser-agnostic API to render and display your pdfs.
Create an HTML form for the user to fill and verify all the information, then render the pdf based on the data supplied by the HTML form, for download only (no previewing in the browser). This will force them to open the pdf in their default pdf viewer where the issue is not present, because, again, the problem you describe only happens in Firefox's embedded pdf viewer and not in other pdf viewers like Adobe Acrobat).
Make sure you have the ZapfDingBats Font installed on your server. I haven't confirmed this, but that commit that was supposed to have solved this issue seems to have added support for this font, so it is worth a try to make sure this font is accessible on your ColdFusion server, then try previewing the rendered pdf in Firefox.
Detect that the user is accessing your form via Firefox, and if so, warn the users of the issue, but assure them that downloading the form and viewing in their default pdf viewer will work as expected.
Convert the page to HTML5 (if you aren't already), then add in an HTML5 shiv (so HTML5 features can be used on older browsers), and a CSS normalizer, and test if the problem persists using these optimal settings. It's worth a shot to make sure that the problem is somehow treated differently under the HTML5 standard, since not everyone is having the same issues as you.
Lastly, make sure that your HTML is being rendered as valid markup via your ColdFusion output by using an HTML validator.
Other than that, there isn't a whole lot you can do until the mozilla team updates their embedded pdf viewer. But since the problem is only in the firefox viewer, and not in the pdf itself, it it up to you to decide if this is a deal-breaker or not, and search for alternatives.
Note: PDF.js is built into version 19+ of Firefox.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Update: You can use this pdf (which represents the character mapping of the ZapDingbats symbol font) as a way of testing your browser's interpretation of embedded fonts in the pdf rendered via pdf.js. Note that at the time of this writing, the above pdf does not display the Zapf Dingbats properly in Firefox (via pdf.js), but other browsers render them just fine (notice the "4" next to a20[x2714] in firefox, and the checkmark next to the same entry (a20[x2714]) in Chrome.
When attempting to click elements using a CSS selector, e.g
browser.find_element(:css, '.login').click
I am seeing different behaviours in different browsers. This is the behaviour I am seeing:
Chrome (35.0.1916.114) - works as expected
Firefox (24.0) - seems to ignore the command and move onto the next line of the test. Either that or it thinks it has clicked the element when it has not.
Safari (7.0.3 (9537.75.14) - complains that the element is not present. Interestingly, this one doesn't even seem to wait until the page has even loaded.
I have tried using a variety of web driver versions (2.42.0, 2.39.0, 2.33.0) and different browser versions with no success.
It turns out that my specific problem was that Firefox doesn't like targeting link elements inside lists, whilst chrome will do it fine. For example:
The following will not work in Firefox:
Browser.find_element(:css, '.list-item')
Whereas this will:
Browser.find_element(:css, '.list-item > a')
This may have been a unique problem for the site I was testing, but it is worth bearing in mind.
I'm running Selenium in singleWindow mode and IE8.
If i start IE8 manually the IE8 mode is set, but when i launch it with Selenium, the mode set is IE7 using the compatibility mode.
Anyone knows why the compatibility mode is not the IE8 view when launching the browser with Selenium?
Or, how can i disable totally the compatibility mode in IE and force it to use always the IE8 view?
I've given the question a +1 because it's a very good question -- it's not obvious how to do this, and if you need to test both modes, then it is a necessary thing to do.
You could get the site to serve <meta http-equiv="X-UA-Compatible" content="IE=7" /> within the page when running the tests. This should force the output mode.
Obviously, that's not ideal, because it means changing your code to produce the meta tag on demand. I'd normally consider it a bad thing if you're having to change the main codebase in to add code for the specific use of your test suite, but in this case I can't see any other solution.
Given that we've decided to go down this path, you could write your code to accept a specified argument in the URL that triggers the meta tag to be served. The IE7 tests could then be written to send that URL argument.
By the way, it's worth pointing out that IE8's IE7-compatibility mode is not 100% identical to IE7; it has its own quirks and bugs which are distinct from those of a real IE7 browser. For the most part it should be fine, but it's worth being aware of this if you're expecting your tests to confirm that the site works in IE7. See this blog post for more info
I have some workarond solution for this, I use it regularly:
In internet explorer goto:
1. Tools / Compatibility view settings.
2. At the Add website input textbox add your website url.
Hope that helps, best regards,
Peter Nadasi (HUN)
It looks like IE7 doesn't reload the latest version of my stylesheet each time I upload a new version on the server.
This is annoying as I am debugging my .css file to make it work on IE...
Tried to empty the browser cache but still not working.
Thanks for your help.
Ctrl-F5 - forcible way to reload in IE
Include your version number in the file name. myfile_v1234.css
When testing, every time you do an update you can just wite "stylesheet.css?r=98123"
As long as the query string is different, it'll be downloaded again.
If you need, you can use javascript to append Math.random(), to get the random number. Not required on production though, when updates would be stable.
2 Questions:
Does IE eventually load with the newer stylesheet?
How are you saving the changes to the server (SSH, Web Interface, etc.)?
I ask because I ran into an issue with a web-based file management system a while back where one browser would show the CSS just fine, the other wouldn't, and we noticed the issue of which browser played nicely depended on which browser we used to upload the CSS.
The reason turned out to be that IE gave the CSS file a different MIME type than Firefox. If you continue to notice the issue even when you've cleared the cache, check the MIME type of the file using Firefox by going to Tools > Page Info.
Also, if it is simply a caching issue, consider turning caching off in IE. I believe this should be an Advanced Option under Internet Options.
Also, you may want to try creating a special developer environment for IE (if it comes down to it.) Perhaps have another machine with IE7 and no caching and any other features turned off (A kiosk mode, perhaps), and then previewing the page on that machine.
Thanks to you all!
I did manage to solve my problem with the "stupid" Ctrl+F5, and by changing the Internet Parameters of Windows to reload content every new visit.
When I am using a form containing <input id="myFile" type="file" runat="server" /> to upload a file, my server-side code only sees the filename without the full path when using Firefox, while it works just fine in IE.
Is it possible to retrieve the full file path server-side in this case?
You cannot. Actually, only IE gives this information which isn't important for the server in most cases. Neither FF nor Opera, at least, provide this info.
[UPDATE] Also tried with Safari, still no path... Somebody reported that Chrome might provide the info, although being a beta, that might change...
Perhaps you might need them in some intranet cases. In such case, you might ask the user to paste the path in a secondary input field... Not very friendly, but at least they will know they provide the info.
Actually, I know some people needed this info for some reasons, so they used JavaScript to pick up the path from the file input field and put it in an hidden field. FF developers found it was insecure (you can learn a lot from a simple path... like the login name of the user!) so prohibited such usage in FF3, making some people angry against this release...
References: Firefox 3's file upload box mentioned in Firefox 3 annoyance: Keying-in disabled in file upload control ...; also File input box disabled leads to great usability problem, among many other ones.
You can never be sure of getting a full filepath or even a reliable filename or content-type submitted in a file upload file. Even if you get a full filepath you don't know what the path separator character is on the client's operating system, or whether a file extension (if present) denotes anything at all.
If your application requires the filepath/filename/content-type of a submitted file for anything more than giving the user a default title for the item uploaded, it's doing something wrong and will need fixing.
I already stated this in a comment, but I think it bears repeating.
Microsoft opted to make the file control give the entire path to the file for use in intranet applications.
The HTML specification only makes mention of what the value should contain in one spot:
User agents may use the value of the
value attribute as the initial file
name.
However, they also have examples of what the multipart/form-data encoding should look like, and it doesn't contain the file path.
In other words, IE is breaking the standard and you can't rely on other browsers, even later versions of IE, to support it.