If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Some pages like Facebook or German Amazon come up with a blank virtual buffer and lots of unknown accessibles

RESOLVED FIXED

Status

()

Core
Disability Access APIs
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: MarcoZ, Assigned: surkov)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
I discovered this while testing a patch for bug 592913, but Jamie indicated that he had seen this before bug 130078 landed. Might be a regression from most recent caching work.
(Assignee)

Comment 1

7 years ago
requesting blocking on this, this is serious problem that should be resolved in timeframe of Firefox4
blocking2.0: --- → ?
(Reporter)

Comment 2

7 years ago
STR:
1. With the special build of NVDA that works with current nightlies (including bug 592913), visit either http://www.amazon.de or www.facebook.com.
2. On Amazon, the problem becomes visible immediately on the front page. On Facebook, the login page still is OK, the trouble starts when getting to the start page after logging in. If you log into Facebook automatically, it'll also be visible on the very first page.

Expected: Virtual buffer should be filled.
Actual: Virtual buffer comes up blank.

3. Press tab to move through elements.

Expected: NVDA should speak focused element.
Actual: NVDA will just say "unknown".
(Assignee)

Comment 3

7 years ago
So, we're waiting for Jamie's response before we take any action on fix, right?
Marco, I'm guessing a regression window is going to be tricky here? Is there a corresponding NVDA sister bug (I couldn't find one)?
(Reporter)

Comment 5

7 years ago
Yes, this is tricky since the builds where recently patches landed don't work for me to test.

However, there was one which I can't remember because I didn't review it I think, that landed shortly before bug 130078, like at most 3 days before that, which puts it in a window of August 24 to August 27 somewhere. Perhaps one of the checkins from those dates in our module having to do with caching springs out at you?
(Assignee)

Comment 6

7 years ago
Marco, could you please list suspected bugs based on time range you pointed out.
Sounds like this is the range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f203095c85de&tochange=01fa971e62ee
(Reporter)

Comment 8

7 years ago
One possible candidate is Bug 589145. The others don't have that effect I *think*. I mean the crash and the assertion fix for bug 574312.

Comment 9

7 years ago
(In reply to comment #0)
> Jamie indicated
> that he had seen this before bug 130078 landed.
My apologies for the confusion. I meant after bug 130078 but before the patch for bug 592913. It's possible that this *did* happen before bug 130078, but I doubt it.

Comment 10

7 years ago
This is weird. When this problem occurs, AccessibleObjectFromWindow with Gecko's HWND and OBJID_CLIENT starts returning a system generated ROLE_SYSTEM_CLIENT object instead of the Gecko top level frame. I'm guessing that Gecko's WM_GETOBJECT is failing for some reason.

More elaborate str and results:
1. Open http://www.amazon.de/ in Minefield.
2. Call AccessibleObjectFromWindow with Gecko's HWND and OBJID_CLIENT.
Expected: The object returned should be the Gecko top level frame.
Actual: The object returned is a ROLE_SYSTEM_CLIENT object generated by the system.
3. Access about:blank from the location bar.
4. Call AccessibleObjectFromWindow with Gecko's HWND and OBJID_CLIENT.
Result (correct): The object returned is the Gecko top level frame.
5. After this, everything is fine until you visit another broken page.

My test case produces different but probably related results. Str:
1. Open http://realgokarts.com/pricing.htm in Minefield.
2. Call AccessibleObjectFromWindow with Gecko's HWND and OBJID_CLIENT.
Expected: The object returned should be the Gecko top level frame.
Actual: The object returned is the content document for the URL in step 1.
3. Access about:blank from the location bar.
4. Call AccessibleObjectFromWindow with Gecko's HWND and OBJID_CLIENT.
Expected: The object returned should be the Gecko top level frame.
Actual: The object returned is a ROLE_SYSTEM_CLIENT object generated by the system.
5. After this, things remain broken in this way until you repeat these steps, at which point everything repeats itself.

Basically, WM_GETOBJECT is returning the wrong root accessible object in some cases and no accessible object at all in others.

Comment 11

7 years ago
Mick, copying you so you know what's going on here.
(Assignee)

Comment 12

7 years ago
here's try server build - http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-4ed62aec12cd/
(Assignee)

Comment 13

7 years ago
Created attachment 473961 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
(Assignee)

Comment 14

7 years ago
Jamie, could give a link to NVDA build that I can try. I need to try to understand what's going wrong here.
(Reporter)

Comment 15

7 years ago
Alex, you can try this build: http://www.jantrid.net/misc/nvda_snapshot_main-3799+noMozillaClassChecks_portable.exe
(Reporter)

Comment 16

7 years ago
I just tested the try-server build, and it fixes the problems for me with the build liked to from above. A regular snapshot with the fix isn't available yet, but will try it as soon as it is.
Approving blocking due to severity (fallout from bug 130078). The patch looks like it is hitting the right spot.
blocking2.0: ? → final+
(Assignee)

Comment 18

7 years ago
(In reply to comment #16)
> I just tested the try-server build, and it fixes the problems for me with the
> build liked to from above. A regular snapshot with the fix isn't available yet,
> but will try it as soon as it is.

Ok, great, I'll try to figure out what's going on here to check the patch makes things right.

Comment 19

7 years ago
(In reply to comment #16)
> A regular snapshot with the fix isn't available yet
Latest NVDA snapshot should include this fix.
(Assignee)

Comment 20

7 years ago
Comment on attachment 473961 [details] [diff] [review]
patch

I can't reproduce the bug on amazon.de. I suggest just to take this patch since it protects us from problems like this.
Attachment #473961 - Flags: review?(bolterbugz)
(Assignee)

Updated

7 years ago
Attachment #473961 - Flags: superreview?(roc)
(Assignee)

Comment 21

7 years ago
(In reply to comment #20)
> Comment on attachment 473961 [details] [diff] [review]
> patch
> 
> I can't reproduce the bug on amazon.de.

I tried 3838 nvda build perhaps it has some protection
Attachment #473961 - Flags: superreview?(roc) → superreview+
Comment on attachment 473961 [details] [diff] [review]
patch

r=me since this patch removes the old logic from when we had more child windows. The fear is that we're missing some cases where this might still be needed. I'm unsure about landing this before further testing. We'll want it in beta7 for sure.
Attachment #473961 - Flags: review?(bolterbugz) → review+
As per discussion with Marco, yeah let's land it.
(Reporter)

Comment 24

7 years ago
Comment on attachment 473961 [details] [diff] [review]
patch

I think we should land this patch to give it some exposure. We're more likely to find problems if everybody using the nightlies and current builds of NVDA 2010.2beta1 can actually play with it.
(Assignee)

Comment 25

7 years ago
landed on 2.0 - http://hg.mozilla.org/mozilla-central/rev/a42e7aef9a62
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 26

7 years ago
(In reply to comment #21)
> > I can't reproduce the bug on amazon.de.
> I tried 3838 nvda build perhaps it has some protection
Nope. However, I can still reproduce it, so I'll try it once the new nightly comes out.
Comment on attachment 473961 [details] [diff] [review]
patch

>diff --git a/widget/src/windows/nsWindow.cpp b/widget/src/windows/nsWindow.cpp
>--- a/widget/src/windows/nsWindow.cpp
>+++ b/widget/src/windows/nsWindow.cpp
>@@ -7608,49 +7608,24 @@ nsWindow::GetRootAccessible()

>+
>+  nsAccessible* docAcc = DispatchAccessibleEvent(NS_GETACCESSIBLE);
>+
>+  nsCOMPtr<nsIAccessibleDocument> rootDocAcc;
>+  docAcc->GetRootDocument(getter_AddRefs(rootDocAcc));

Hmmm should probably null check docAcc before using it.
(Assignee)

Updated

7 years ago
Depends on: 597311
You need to log in before you can comment on or make changes to this bug.