User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre Several major German banks (like Sparkasse and Postbank) are migrating their customers from the PIN/iTAN system to the new chipTAN system. This system involves a hardware TAN generator used to authenticate transactions. The device is held against a flicker code on screen and receives the transaction data via five optical sensors. See http://www.kobil.com/fileadmin/Documents_2009/Video/DEMO_CHIP_TAN.swf for a demonstration. This works very well with Firefox 3.6.13 (both Windows and Linux). It works much worse with Firefox 4 on Windows (several tries necessary). It fails completely with Firefox 4 on Linux. Reproducible: Always Steps to Reproduce: 1. Disable Flash 2. Visit https://bankingportal.sskduesseldorf.de/portal/portal/StartenIPSTANDARD 3. Click "Demokonto Online-Banking" on the left hand side 4. Click "chipTAN testen" in the middle 5. Login with demo account (id and password given on top) 6. Click "Überweisung" in the middle 7. Click "Empfängerdaten" on the left hand side 8. Click the Euro symbol on the "Tina Test" account 9. Enter an amount and click the "Weiter" button below 10. The flicker code is displayed 11. If you have a device available: Try to read the code 12. If not, observe the flickering of the leftmost bar Actual Results: The display update is erratic, the leftmost bar flickers much more slowly in Firefox 4. The code is not recognized by the device on Linux (openSUSE 11.3). The code is only recognized by the device after an extended period of time on Windows XP. The problem can be reproduced on different hardware. Expected Results: The display update is so fast that the leftmost bar almost seems gray. The code is recognized by the device immediately. There are two workarounds: 1. Install and enable a Flash plugin 2. Circumvent the flicker code by manual data entry on the device keyboard Method 1 will be used reluctantly by security-aware customers. Method 2 is cumbersome and error-prone.
>11. If you have a device available: Try to read the code My device reports "transmission successful" with Seamonkey trunk on win7 with or without flash but it often retries the transmission one time without. The difference is difficult to see on win7. It's not possible for me to find a regression range with such a small difference. Reporter: Would you help to find the regression range ? You have to download multiple nightly builds and test them.
Regression range: GOOD: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091231 Minefield/3.7a1pre FAIL: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100101 Minefield/3.7a1pre
I need the build revision from both builds that you can see in about:buildconfig An example is "Built from http://hg.mozilla.org/mozilla-central/rev/26421a3b68f3" The date is interesting, i hope it's not some stupid UA sniffing
Build revisions: GOOD: http://hg.mozilla.org/mozilla-central/rev/6d56925adfd5 FAIL: http://hg.mozilla.org/mozilla-central/rev/cb5a303025fe
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6d56925adfd5&tochange=cb5a303025fe Boris: I hate it to steal your time but can you help here ?
What flicker frequency does this thing expect to get? will69, thanks for the detailed steps to reproduce. Unfortunately, visually the flicker looks about the same to me on trunk and on branch and I don't have a device to test. But if you're willing to experiment a bit.... what happens if you set the "layout.frame_rate.precise" preference to true in about:config? It looks like the page is toggling style.visibility from hidden to visible on the images in question to create the flicker; it should all be happening at once (off the refresh driver), so the simultaneous display issue raised in comment 5 should not be a problem.
> i.e. 8.33fps Well, refresh driver can _definitely_ handle that. > This had an impact on visual appearance, but it didn't help to recognize the > flicker code. This is when I start really wishing your device had diagnostics that told me what it's thinking.... ;) > Firefox 4b12 + Xorg 1.8.0 use 100% CPU for the flicker code Interesting. I wonder whether X is failing to keep up with updates here for some reason. But the regression range certainly looks like refresh driver. What values did you try for "layout.frame_rate", by the way? If they try to drive the flicker at a higher frequency than our refresh driver goes I can see us skipping frames, but then again so does your 60Hz LCD if they try to go at more than 60Hz...
OK, looks like the relevant script is https://bankingportal.sskduessledorf.de/js/flicker91.js. This script tries to drive the flicker at 100Hz by default (opttanDefaultDelay is in ms), which is faster than monitors actually update. So this will drop frames. With refresh drive it might possibly drop more frames than before... maybe. Put another way, I have no idea why this ever worked. ;) And yes, that first bar is a clock signal, looks like, based on reading that source.
Oh, for comment 11 you need to do that on the page the flicker code is shown on, and then reload the page for it to take effect. I should also note that if they used mozRequestAnimationFrame here this would all Just Work... :(
So, this doesn't sound like a blocker to me based on comment 10 and comment 11 - it actually sounds like an INVALID. Renominate if I missed something.
I think we should strongly consider evangelizing the site to fix their default timeout or to expose a user control to change the flicker rate.... Again, I don't understand how this could have worked before. roc, thoughts?
If this is only failing for Linux users then I think it's not worth trying to work around (which sounds incredibly painful). We should evangelize the site(s).
Finanz Informatik has changed the delay value to 20ms (50fps) in flicker91.js. This fixes the problem for all German Sparkasse online banking sites.