Closed Bug 627816 Opened 14 years ago Closed 14 years ago

Loading BlindCoolTech never sends a "document finished loading" to NVDA

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: MarcoZ, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

STR: 1. Run a current nightly. 2. Load NVDA. 3. Open http://www.blindcooltech.com 4. Listen as NVDA says "BlindCoolTech podcast, document busy". Expected: After a very short while, it should start reading the page. This is one of the sites where we improved perf dramatically in FX 4. Actual: It never continues, regardless of how long you wait. 5. Alt-Tab away. 6. Alt-Tab back. Result: Now, NVDA loads the site into the virtual buffer. 8. Press CTRL+R to reload. 9. Go to Go to step 4. This can repeated at will.
Wow. Testing nightly with NVDA 2010.2, I can't get arrow navigation to work at all (refreshing the virtual buffer or not).
I so see an IA2_EVENT_DOCUMENT_LOAD_COMPLETE event (in accprobe).
Data point: in 3.6 we seem to fire a statechange on the doc before the load complete, and in nightly this statechange comes after.
(In reply to comment #2) > I so see an IA2_EVENT_DOCUMENT_LOAD_COMPLETE event (in accprobe). As noted in another bug (which I can't seem to track down), NVDA will not load a buffer for a document if it has the busy state. My suspicion is that the document still has the busy state briefly after the documentLoadComplete event is fired. Interestingly, I can't reproduce this, despite trying several times with both NVDA 2010.2 and a current dev build. If I wait a few seconds, the page renders just fine. I'm using: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110117 Firefox/4.0b10pre
Mick, can you reproduce this?
Marco, can you give me a regression range please?
I can not reproduce this exactly with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre and NVDA main 4047. After a second or two I do get NVDA loading the page and starting a say all. However, I do notice that the application main frame seems to have the busy state, I'm not sure if that's strange or related? I should also note that I have seen the described problem on some other pages before, especially my Billian ADSL router web interface. However, on blind cool tech it works fine for me.
I tried 20 and 21 Jan build, can't reproduce. Funny thing the content is available for screen reader users only now.
I still can reproduce this at will with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre, and I confirmed bug 498015 is the culprit. It may also depend a little on which window I try to load BlindCoolTech in. I'm still on NVDA 2010.2. And yes, I do get that busy state problem quite often on varying pages as well.
Marco, can you check if we deliver document loaded event at all (similar to bug 626647) when you see a problem?
David already confirmed we're firing the document_load_complete event, but we're firing the state_change to clear the busy state *after* that, whereas in Firefox 3.6, the state change came before the doc load complete. See Comment #3.
(In reply to comment #11) > David already confirmed we're firing the document_load_complete event True, but was he actually able to reproduce the bug? > we're firing the state_change to clear the busy state *after* that Just to be clear, this in itself isn't a problem. The key point is that the busy state must not be set when NVDA processes the documentLoadComplete event.
Marco, can you do some experiments on you local build? 1) keep turned off busy state always 2) do not turn on busy state when it was turned off
(In reply to comment #12) > (In reply to comment #11) > > David already confirmed we're firing the document_load_complete event > True, but was he actually able to reproduce the bug? Yes, he said so on IRC. > > we're firing the state_change to clear the busy state *after* that > Just to be clear, this in itself isn't a problem. The key point is that the > busy state must not be set when NVDA processes the documentLoadComplete event. And I *believe* that is the case because you are receiving the document_load_complete, but the busy state isn't cleared yet. So you think you can start processing, but we haven't notified you that the busy state is also gone. In FX 3.6, we clear the busy state before we even send you the event that the doc has finished loading. Sometimes, you may start processing the document when we have cleared the busy state, and sometimes not. The results I'm seeing are indicating a lingering timing problem, and BlindCoolTech was just a site where I, on my machine, can reproduce this at will. We send you the state change too late that the doc is no longer busy. (In reply to comment #13) > Marco, can you do some experiments on you local build? > > 1) keep turned off busy state always > 2) do not turn on busy state when it was turned off Can you give me pointers where I need to change this in the code? With all the code reorg I lost track a bit where we set and clear those flags...
(In reply to comment #13) > Marco, can you do some experiments on you local build? > > 1) keep turned off busy state always > 2) do not turn on busy state when it was turned off but it doesn't really look like the busy state is guilty here, perhaps we deliver document loaded event before we create accessible tree (not sure how that may happen), but if that happens then bug 606924 (patch 3) should help.
(In reply to comment #14) > (In reply to comment #12) > > (In reply to comment #11) > > > David already confirmed we're firing the document_load_complete event > > True, but was he actually able to reproduce the bug? > > Yes, he said so on IRC. > > > > we're firing the state_change to clear the busy state *after* that > > Just to be clear, this in itself isn't a problem. The key point is that the > > busy state must not be set when NVDA processes the documentLoadComplete event. > > And I *believe* that is the case because you are receiving the > document_load_complete, but the busy state isn't cleared yet. So you think you > can start processing, but we haven't notified you that the busy state is also > gone. In FX 3.6, we clear the busy state before we even send you the event that > the doc has finished loading. > > Sometimes, you may start processing the document when we have cleared the busy > state, and sometimes not. The results I'm seeing are indicating a lingering > timing problem, and BlindCoolTech was just a site where I, on my machine, can > reproduce this at will. We send you the state change too late that the doc is > no longer busy. > > (In reply to comment #13) > > Marco, can you do some experiments on you local build? > > > > 1) keep turned off busy state always > > 2) do not turn on busy state when it was turned off > > Can you give me pointers where I need to change this in the code? With all the > code reorg I lost track a bit where we set and clear those flags... Sure 1) disable if condition - http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsDocAccessible.cpp#323 2) disable MarkAsLoading() - http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsAccDocManager.cpp#219
(In reply to comment #14) > And I *believe* that is the case because you are receiving the > document_load_complete, but the busy state isn't cleared yet. So you think you > can start processing, but we haven't notified you that the busy state is also > gone. In FX 3.6, we clear the busy state before we even send you the event that > the doc has finished loading. You should keep in mind that busy state flag and busy state change are different things. Busy state flag (nsDocAccessible::MarkAsLoaded()) is set before we send document loaded event.
(In reply to comment #14) > > Just to be clear, this in itself isn't a problem. The key point is that the > > busy state must not be set when NVDA processes the documentLoadComplete event. > And I *believe* that is the case because you are receiving the > document_load_complete, but the busy state isn't cleared yet. So you think you > can start processing, but we haven't notified you that the busy state is also > gone. To clarify further, my point was that we don't care about the stateChange *event*; we just care that the busy state isn't there when we query the states. In other words, hypothetically, even if you didn't fire a stateChange event at all, it wouldn't matter to us as long as the busy state wasn't present when we handled the documentLoadComplete event. I only mention this because it might help you narrow down where to look.
Is NVDA monitoring the document load events in or out of context?
(In reply to comment #19) > Is NVDA monitoring the document load events in or out of context? Out of context.
Accprobe does not see the busy state when it queries for state from the document load complete accessible. (In reply to comment #7) > After a second or two I do get NVDA loading the page and starting a say all. > However, I do notice that the application main frame seems to have the busy > state, I'm not sure if that's strange or related? It is strange, we probably don't ever want that to have the busy state (not sure). Bug 613146 should have resolved any busy state problems with document load events. Is there anything else that NVDA looks at to delay creating the VB?
(In reply to comment #21) > Accprobe does not see the busy state when it queries for state from the > document load complete accessible. ... > Is there anything else that NVDA looks at to delay creating the VB? The document must have the read only state, but i assume that is already true. The following might be worth a try: 1. Start NVDA. 2. Open the NVDA Python console. 3. Paste the following lines (you'll need to paste each line separately and press enter after each one): from NVDAObjects.IAccessible.mozilla import Mozilla Mozilla.event_documentLoadComplete = lambda self: log.info( "Mozilla documentLoadComplete! " + "\r".join(self.devInfo) (In reply to comment #7) > However, I do notice that the application main frame seems to have the busy > state, I'm not sure if that's strange or related? I think that's a different bug which exists in Firefox 3.6 as well. For example, right now, my top level frame is busy, and from memory, it's busy most of the time these days. There was some discussion of it in bug 494802, but I don't think it was ever fixed.
(In reply to comment #22) > (In reply to comment #7) > For > example, right now, my top level frame is busy, and from memory, it's busy most > of the time these days. It could quite possible for Firefox window document accessible. Do you check busy state in ancestor chain when you get document loaded event for the document, right?
(In reply to comment #23) > > For > > example, right now, my top level frame is busy, and from memory, it's busy most > > of the time these days. > It could quite possible for Firefox window document accessible. Do you check > busy state in ancestor chain when you get document loaded event for the > document, right? No. We only check the busy state on the document for which the documentLoadComplete was fired. Otherwise, documents would rarely ever load for me. :) I just mentioned it in response to Mick's observation.
This bug is no longer reproducible for me. It appears to have been fixed by recent checkins.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Verified WFM in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110126 Firefox/4.0b11pre
Status: RESOLVED → VERIFIED
Depends on: 49815
Sorry for the spam, wrong bug number. Bug 606924 fixes this, bug 498015 originally created the problem for me, but cannot mark this because it would cause a circular dependency.
Depends on: 606924
No longer depends on: 49815
You need to log in before you can comment on or make changes to this bug.