Closed Bug 376887 Opened 15 years ago Closed 15 years ago

document frame sometimes claims 0 children, or sometimes contains incomplete content

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jdiggs, Assigned: aaronlev)

References

(Blocks 1 open bug, )

Details

(Keywords: access)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070408 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070408 Minefield/3.0a4pre

Periodically certain pages are not fully exposed/rendered through AT-SPI.  In those instances, the document frame claims to have 0 children.

Unfortunately, I cannot reproduce this problem reliably, but it seems to occur with slashdot often enough as well as with the Orca wiki (live.gnome.org/Orca). When the problem does occur, using Orca to access the page contents is at best hit-or-miss.  

Reproducible: Sometimes

Steps to Reproduce:
1. Launch Accerciser or AT-POKE
2. Navigate to slashdot.org or live.gnome.org/Orca
3. Once the page has fully loaded, examine the page structure with Accerciser/AT-POKE
Actual Results:  
Sometimes the document frame will claim to have 0 children.

Expected Results:  
All of the children of the document frame would be present/exposed.
Blocks: orca
Keywords: access
Is it a regression?

Also, just a nit: you'll notice I keep moving your bugs to product = Core (instead of product = Firefox). The only bugs that should go into Firefox would be issues specific to one dialor or another. Any general issues with HTML or the XUL UI widgets should go into Core. That's almost everything.
Assignee: nobody → aaronleventhal
Blocks: atk
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
> Is it a regression?

To be honest, I couldn't tell you.  It was reported as an Orca bug by Mike Pedersen towards the end of March (officially logged on the 28th at: http://bugzilla.gnome.org/show_bug.cgi?id=423534). Mike indicates that he can reproduce it reliably.  And I believe he uses slashdot frequently and might, therefore, be able to give you some indication as to when this issue manifested itself.  Thus I'm adding Mike to the CC list.   If I could reproduce it reliably, I'd go back to earlier versions myself to see if I could find the point at which it was introduced.  Perhaps Mike could also give that a try should he have the time??

> Also, just a nit: you'll notice I keep moving your bugs to product
> = Core (instead of product = Firefox). 

Noticing now. :-) Sorry.... Thanks for pointing that out!
This bug makes me nervous.

Joanmarie, have you seen this bug in a while? Any new info?
> Joanmarie, have you seen this bug in a while? Any new info?

Thanks for the ping.  Yes, I'm still seeing it.  I just spent an hour really looking at it in the hopes that I could reproduce it more reliably.  I think I can now.  

1. Boot
2. Launch either Orca or LSR (I tried with the most recent versions of each from svn trunk)
3. Launch Firefox 3 (nightly build)
4. Navigate to slashdot.org
5. Optional:  Quit whatever screen reader you chose in step 2
6. Launch Accerciser and look at the hierarchy.  The document frame claims 0 children.

Other observations:

If you cut out step 2, the problem doesn't occur.  Having *some* screen reader running first seems key.  I even tried launching Accerciser and turning on monitoring of all events in lieu of step 2.  The document frame still claimed all of its children.

If you reload the page, the problem goes away -- whether a screen reader is running or not at the time you do the reload.

Once the page has loaded correctly, the problem will not manifest itself again until you reboot.  Even if you quit everything and begin with step 2.  The document frame will continue to claim all of its children.

In the "surely this is irrelevant, but I haven't had time to weed it out" department:  The page that loads each time I launch Firefox is netvibes.com. (i.e. I'm going from netvibes to slashdot) The way I navigate to slashdot is <Alt+D>, type the URL, <enter>.

I hope this helps!

p.s.  Most folks call me "Joanie".  You should feel free to as well. <smile>
Aaron, with respect to your question from a couple of weeks ago:

> Is it a regression?

Now that I can reproduce it reliably, I grabbed the earliest trunk build I saw:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070228 Minefield/3.0a3pre

The problem exists there as well.
Joanmarie, thanks! That's great information.

Ginn, will you be able to look at this?
Assignee: aaronleventhal → ginn.chen
reproduced. interesting steps.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It claims 0 child, because query interface to nsIAccessibleHyperText fails,
that is because IsHyperText() fails,
that is because nsHyperTextAccessible thinks it has 0 child.

So the problem is InvalidateChildren() should be called at some time, but it wasn't.

> p.s.  Most folks call me "Joanie".  You should feel free to as well. <smile>
Joanie, I just saw that now! Oops :)

Ginn, my guess is that nsDocAccessible::mIsContentLoaded is not set for the doc accessible when an nsDocAccessible is created for an already loaded document.

That must be causing some kind of invalidation not to be called, maybe this?
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#752
Assignee: ginn.chen → aaronleventhal
Ginn, I'm probably wrong about mIsContentLoaded. It should be set here:
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#119
We need to investigate more.

I didn't mean to reassign this to myself. Back to Ginn.
Assignee: aaronleventhal → ginn.chen
netvibes.com needs to be the first page.
The second page can be anything.
I was just on the phone with Michael Pedersen and mentioned your finding Aaron.  He indicated that the way he typically gets to slashdot is from his personalized Google page (i.e. he's also starting from a page which includes AJAX).
Aaron, interesting, I looked at mIsContentLoaded for first guess, too.

I reproduced this with several pages.
Sometimes I need to logout and relogin gnome to reproduce it. 
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#752
Invalidate its parent, nsOuterDocAccessible, but didn't invalidate itself.

I'm not sure it should be the right place to invalidate nsDocAccessible.

Add either
InvalidateChildren() or
InvalidateCacheSubtree() here seems can solve it. 
Attached patch patchSplinter Review
Attachment #263003 - Flags: review?(aaronleventhal)
Comment on attachment 263003 [details] [diff] [review]
patch

Ginn, I'm concerned that you might be doing InvalidateChildren() on the newly created nsDocAccessible, because aIsFinished means the doc is finished loading and ready for use.

Can you investigate and find out why this bug doesn't happen on Windows? That's an important clue to how we need to fix it.
Attachment #263003 - Flags: review?(aaronleventhal) → review-
Blocks: lsr
Aaron, yes, I'm doing InvalidteChildren() for newly created nsDocAccessible.

The timeline is,
---nsDocAccessible is created
---Orca tries to get child count of newly created nsDocAccessible
   mAccChildCount = 0
---load finished, mIsContentLoaded = isFinished = PR_TRUE;
---Orca or at-poke tries to get child count of nsDocAccessible
   still get 0

So we want to reset mAccChildCount when it's finished, right?
Or, we can keep mAccChildCount == -1 if !mIsContentLoaded

This bug doesn't happen on Linux, if I don't run Orca.
I guess the point here is, if Orca is not trying to get the child count of nsDocAccessible during loading, mAccChildCount is -1.
It's the same result of doing InvalidteChildren().
After it's loaded, we can get the correct result of GetChildCount then.
Ginn, your explanation makes sense to me.

We obviously need to fix it Firefox.
Orca might also want to make a change -- it would be good to find out what is causing Orca to create accessibles. I wouldn't consider that a bug in Orca, but perhaps for optimization Orca might want to wait until the load is finished. Anyway we should at least know what is causing the creation of accessibles during document load. We might find more errors in Firefox that way.

As far as the Firefox fix -- I think there might be other accessibles inside the document that don't get properly invalidated.  A descendant may have had it's children created before the document is fully loaded.
Attached patch Adding more on top of Ginn's fix (obsolete) — Splinter Review
Ginn, does this fix the bug even if your fix is not in there?

Explanation:
1) STATE_STALE is correct (not exactly part of the fix, but that's what state the document is in while it's still loading)
2) If the document thinks it knows how many children there are, don't exist InvalidateCacheSubtree() early -- finish the work (which should ultimately InvalidateChildren() on the document). This should make your other patch unnecessary, but we should probably keep it just to be safe.

Still looking to find out why Orca tried getting the children during document load. Did we fire an event it responded to?
Assignee: ginn.chen → aaronleventhal
Status: NEW → ASSIGNED
Attachment #263281 - Flags: review?(ginn.chen)
Comment on attachment 263003 [details] [diff] [review]
patch

+    // Finished loading, invalidate its children
how about
+    // Finished loading, invalidate its children, because the AT may have attempted to get children before they were all there

Ginn, do you think we still need this if the other part of the patch is in?
Attachment #263003 - Flags: review- → review+
> Orca might also want to make a change -- it would be good to find out what is
> causing Orca to create accessibles. I wouldn't consider that a bug in Orca, but

Good question.  I am still going over the debug output I just captured when the problem was occurring versus when it wasn't.

In both cases I'm going from Netvibes to Slashdot after having typed the URL for slashdot in the address bar and pressed Enter.

In both cases, we get a focus event for the document frame before the new page has loaded (i.e. the name of the object is "My Netvibes (x)").  When the problem does not occur, the document frame has the following states:

* Busy
* Focusable
* Focused
* Showing
* Visible

When the problem does occur, the document frame has only one state:

* Focused.

I believe it is our intent, as you suggested, to wait until the page has finished loading.  I'm guessing that we're seeing that the BUSY state is no longer present and assuming it has loaded.  That might also explain why the problem seems to occur in LSR as well.

But I'm the new kid on the block, so I'm CCing Will to see what he thinks.
You know, we're not assuming it loaded because the BUSY state is no longer present.  But it seems we ARE attempting to access the document frame because of the focus event.  I may be able to do some fixing on the Orca end....
Comment on attachment 263281 [details] [diff] [review]
Adding more on top of Ginn's fix

Aaron, I can still reproduce this issue with your part of patch only.

I'm out of office today, I tested under vmware.
I even reproduced several times without orca running.
I've no idea which AT is calling getChildCount.
Attachment #263281 - Flags: review?(ginn.chen) → review+
Aaron, I think your patch doesn't work because it doesn't change the routine of nsAccessible::CacheChildren().
mAccChildCount will be set zero there.

We could prevent it by overriding GetChildCount.
I don't think it's neccessary
(In reply to comment #22)
> You know, we're not assuming it loaded because the BUSY state is no longer
> present.
That should be a correct assumption. Ar eyou sure that the BUSY state is clear on the document when yo ustart to walk it?

I'm tempted to check in both Ginn & my fix, but I don' think we understand the whole story yet.

Ginn, why is GetChildCount() being called at the wrong time in the first place? Why are they seeing the wrong states when the problem occurs, as described in comment 21?
Ginn, with this patch we don't need the change to FireDocLoadEvents()

I debugged this and found that if the content area was previously focused, we fire a new doc focus as soon as the newly loading document is visible. However, just because it's visible doesn't mean it has finished loading yet.

This patch makes sure we continue to Invalidate() as the doc loads, even if it has finished loading yet. This will catch more problems with incorrect cache info than just the InvalidateChildren() addition to FireDocLoadEvents().

This also fixes bug 373575, and probably fixes our longstanding issues with JAWS only partially loading some pages (and other times not loading them at all).
Attachment #263281 - Attachment is obsolete: true
Attachment #263650 - Flags: review?(ginn.chen)
Duplicate of this bug: 373575
Summary: document frame sometimes claims 0 children through AT-SPI → document frame sometimes claims 0 children, or sometimes contains incomplete content
We might want to take some safe version of this fix for the 1.8 branch.
So here's the time line when the bug happens:
1. Load starts
2. Focus on document, doc accessible is created
3. Load finishes

Open question: should Mozilla fire children-changed events for loading content after 2 and before 3? Normally we suppress all the children-changed events during that period, because we assume it is an unnecessary amount of calculation. When the load is complete the AT will need to refetch the document content if it's caching that.
Comment on attachment 263650 [details] [diff] [review]
Complete changes to InvalidateCacheSubtree()

Ginn is on vacation
Attachment #263650 - Flags: review?(ginn.chen) → review?(surkov.alexander)
Keep in mind I'm only now catching up on this bug...

My gut reaction is that all children-change events should be suppressed until
after #3. The document is in some transient state between #2 and #3. Any
information indicated by event fired during this time has to be considered
stale by the AT after #3. Under this assumption, the events between #2 and #3
are useless.
Technically the user can start interacting with the document before it's fully loaded. That's part of what we love about the web. Each AT needs to think about how to deal with that fact. You can't really announce a page summary until it's fully loaded, and any initial Javascript to set up the page hasn't even run yet. Despite this, it's very common to start reading, activating links or filling out forms before the page has completely loaded.

Does it really just create problems for a screen reader to allow this? Or is it a feature, as it is for sighted users, that makes the web seem more performant than it really is.

Food for thought.
> Does it really just create problems for a screen reader to allow this? Or is it
> a feature, as it is for sighted users, that makes the web seem more performant
> than it really is.

Orca currently just waits at the moment, but it definitely would be nice to be able to afford people with disabilities the same optimizations in the future.  For now, it seems like fixing the main problem would be the best, and then look to changing things later after we consider what the user experience should be like for navigating content while it is being loaded.

Thanks for all the work!
Attachment #263650 - Attachment is obsolete: true
Attachment #263719 - Flags: review?(surkov.alexander)
Attachment #263650 - Flags: review?(surkov.alexander)
Comment on attachment 263719 [details] [diff] [review]
Complete changes to InvalidateCacheSubtree()

looks ok
Attachment #263719 - Flags: review?(surkov.alexander) → review+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Will someone please verify this in tomorrow's build?
(In reply to comment #37)
> Will someone please verify this in tomorrow's build?

Heck yes! :-)  Thanks for all your work on this. 

You're welcome. Also check the partial load test cases from bug 373575.
This seems to be fixed (as do the partial load test cases).  Thanks much!
You need to log in before you can comment on or make changes to this bug.