837586 - In Firefox 20 (Aurora), pages with iFrames break iSimpleDOM access

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. Download current Aurora build (Firefox 20).
2. Start JAWS. It must be JAWS since that's the screen reader with who this is easiest to reproduce. NVDA does not show this bug.
3. Start Aurora. Note start Aurora *after* JAWS.
4. The start page loads.
Result: Page reads as normal, virtual buffer has content.
5. Now load http://www.mozilla.org, a page that does not contain iframes.
Result: Page reads OK, too.
6. Now load http://www.usatoday.com or http://www.marcozehe.de, both pages that contain iframes.
Expected result: Page should read as well.
Actual result: Virtual buffer breaks, is empty, JAWS says "no links", "no headings". The only way to recover is by closing Aurora and reopening it, but as soon as one re-visits a page with iframes, breakage occurs again. Note that this affects *all* pages that have a Facebook Like or a Google +1 button iframe.

7. Trying to reproduce this bug with Nightly (Firefox 21) proves unsuccessful. Whatever fix there is in Nightly, prevents this bug from happening, but Aurora definitely shows it.

Most likely, this is a negative side effect of bug 767756, the iSimpleDOM tear-off refactor which landed in 20.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco, if you can reduce the fix window that might help.

Alexander any hunches?

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking this regression so we don't ship with it.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #1)
> Marco, if you can reduce the fix window that might help.

that'd be awesome

> Alexander any hunches?

I hoped Trevor will take a look. Maybe that was not a11y regression/fix.

Comment 4

[Marco Zehe (:MarcoZ)]

Attempting to track down a regression range proves difficult. First of all, 20.0a1 (nightly) made on January 7, 2013, did not exhibit this bug. So the bug never existed in the Nightly that was becoming Aurora later that day.

Second, for an unknown reason, the same Aurora build that reproduced the bug for me yesterday *reliably*, works flawlessly today. No changes were made to the profile in the meantime, the only thing that was done was a Windows reboot. But even yesterday, that same Windows had just been booted fresh, and only Aurora had been installed before the bug was reproduced.

Also, no weekly snapshot builds of Aurora made on January 8, 15, 22, and 29, reproduce the bug for me.

I will check back with the user to see if an update to the latest Aurora build fixed the problem for him as well, or if he still sees it. I will also keep looking out for it, but so far have been unsuccessful in trying to reproduce it today, with STR that reproduced it yesterday. :(

Comment 5

[Trevor Saunders (:tbsaunde)]

> I hoped Trevor will take a look. Maybe that was not a11y regression/fix.

without ranges for when this got fixed and when it actually regressed its really hard to say I have no immediate suspects.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> > I hoped Trevor will take a look. Maybe that was not a11y regression/fix.
> 
> without ranges for when this got fixed and when it actually regressed its
> really hard to say I have no immediate suspects.

I see, let's wait for feedback from Marco.

Comment 7

[Marco Zehe (:MarcoZ)]

Even the community member who reported the bug to me initially no longer seems to be able to reproduce it with the latest Aurora update. I'll keep this bug open for a few days and continue testing, and if it no longer turns up either for me or for the user, will close it on Monday Feb 11.

Comment 8

[Marco Zehe (:MarcoZ)]

Current status as of February 11, 2013: I haven't been able to reproduce the bug ever since reproducing it *once* a week ago. Reporting community member reported an instance on Friday Feb 8, about 5 days after reporting it to me initially.

I have not been able to reproduce in nightly.

Suggestions:
1. Keep this bug open for now.
2. Wait for feedback when Firefox 21 hits the Aurora channel in about a week and builds go out to those on that channel. I'll ask the community member to try and recreate the bug. We've had a few more changes in the code area in question which may have stabilised the problem.
3. if the problem goes away, stop tracking this bug and maybe release-note it that it *can* intermittently happen, and to close and reopen Firefox if it does, also indicating that the problem no longer occurs in Firefox 21.
4. Investigate further if 21 does not fix the problem for the user, or if I can manage to reproduce in the meantime.

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco we've had almost a week with 21 in Aurora - any reports?

Comment 10

[Marco Zehe (:MarcoZ)]

None.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Let's removing tracking until someone can reproduce this.

Comment 12

[Marco Zehe (:MarcoZ)]

Fixed by properly reimplementing the IUnknown interface.