Closed Bug 392153 Opened 15 years ago Closed 15 years ago

Form to file a bug is missing from MSAA tree

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: MarcoZ, Assigned: aaronlev)

References

(Blocks 1 open bug, )

Details

(Keywords: access)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081305 Minefield/3.0a8pre

When trying to file a bug with Minefield, the complete form to enter the bug information is missing from the MSAA tree. Neither JAWS 8.0, nor AccExplorer are able to find the information. One paragraph ends with "and check to see...", and the next starts with "actions..." Everything starting from heading level1 "Step1" onwards is not present.

Reproducible: Always

Steps to Reproduce:
1.Go to the url https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=guided
2.With Firefox 2, there is a heading level 1 called "step 1".
3.Minefield does not show this with either JAWS or when exploring the document with AccExplorer.
Actual Results:  
Content is missing from the page.

Expected Results:  
All content should be visible as with Firefox 2.0.
Surkov, can you look at this?

Ginn/Evan, this is probably missing in ATK as well.
Assignee: aaronleventhal → surkov.alexander
Blocks: ia2
Keywords: access
Flags: blocking1.9?
(In reply to comment #1)
> Ginn/Evan, this is probably missing in ATK as well.

No, this is only happening on Windows. I just double-checked with today's nightly, and the form is definitely present and readable with Orca. It's only Windows that's missing this content.
confirm, the first paragraph is exposed only (the content from 'step 1 of 3' to 'Actions: Home, New, ' is absent). It's crossplatform bug. Apparently ORCA acts somehow else because DOMi doesn't show that tree too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
surkov,

I can see all the content exposed in DOMi on Linux.

I didn't test it on Windows yet.
(In reply to comment #4)
> surkov,
> 
> I can see all the content exposed in DOMi on Linux.
> 
> I didn't test it on Windows yet.
> 

I do not get. I can't reproduce the bug on Windows again. AccExplorer and DOMi shows correct tree.
Marco, do you get 100% repeatability of the bug by AccExplorer and DOMi?
(In reply to comment #6)
> Marco, do you get 100% repeatability of the bug by AccExplorer and DOMi?

Alexander, I rechecked, and there seems to be a difference between calling up the URL directly and going there by clicking New -> Other Products -> Core. Previously, I would always get the missing content. Today, I only get the missing content if I:
1. Open https://bugzilla.mozilla.org, login if not already logged in automatically.
2. Click on New.
3. Click on Other Products.
4. Click on Core.
5. The page that now comes up shows the missing content for me 100% of the time.

Again, going through these steps shows the missing content, calling the URL directly no longer exposes the bug for me.
I couldn't reproduce it with latest trunk on either Linux or Windows.
(In reply to comment #8)
> I couldn't reproduce it with latest trunk on either Linux or Windows.

Ginn, I still see it with build 2007-08-19-05. Following my steps in comment #7 still gives me the missing form on Bugzilla. I also see missing content on many other pages intermitantly, sometimes depending on what dynamic ad is being inserted, which makes it difficult to reproduce. But this Bugzilla form thing has been a 100% repro for me.
More info, after talking with Ginn on IRC, and he still couldn't reproduce, I did some more testing and found out that this bug only surfaces if JAWS is running alongside when going through the steps in my earlier comment. If JAWS is not running, AccExplorer will find the form and all the rest of the page content.
This, however, only happens with JAWS 8 and Firefox 3. Firefox 2 is not affected by this bug.
I went back through the builds on archive.mozilla.org and found that this behaviour started on the August 12, 2006 build. Before that, the page would always be loaded completely, from that August 12, 2006 build onwards, it would inconsistently stop processing content at various points. The October 3 build, which introduces the second stage of bug 391490, often shows the behaviour I also see with Alpha8Pre now, but sometimes also simply truncates the content before the form starts.
In conclusion, something changed between the August 11, 2006 and August 12, 2006 builds that introduces this problem.
Reviewing the patches from August 11, I only found this one which could have something to do with it: Bug 231830. Could someone take a look and see if the code to fix that bug could have a negative affect on accessibility?
This kind of behavior, where a page is partially loaded, occurs when there is a crash in Firefox. MSAA swallows the crash but does not return from the method call. JAWS does not know what happened and gets confused.
The way to find a crash like this is to run in Visual Studio. Before you run, enable all exceptions (Ctrl+Alt+E brings up the debug exceptions dialog in Visual Studio).

Additional info: we have a separate bug open to pass these swallowed crashes to the new breakpad crash reporting system. That will make these mystery bugs easier to debug. It's bug 381049.
I am unable to reproduce this with JAWS 8 and a recent trunk build.
I still see this in the latest nightly trunk builds. However if I am running with a debug build made on my machine, I do not see it. The execution is a bit slower then, so I am inclined to thinking that this is a timing issue. If I hit Refresh on the given page, the form appears also in the nightlies. And I do not get any crashes when loading this page at all.
Here are additional URLs that *all* come up with missing or corrupted content when JAWS is running while the page loads. If I quit JAWS, reload each of these pages, then start JAWS again, all content is visible. Can anyone reproduce any of these?
Url #1: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-03+00%3A00&maxdate=2007-08-04+09%3A00&cvsroot=%2Fcvsroot
Result: First of the tables with checkins is cut off after first row of data.
This also happens with lots of other Bonsai queries I've added to various bug reports over the past couple of days. The symptom is always the same: One of the tables is cut off somewhere in the middle, and the next table is then rendered.

Url #2: http://blog.marcocantu.com
result: Blog entries are missing alltogether. If I try to debug this one while JAWS is running, I'm getting loads and loads of steps, and at least one of them is an access violation. But I can't be certain since the moment I halt Firefox, JAWS is halted along with it.
I'm able to duplicate it on URL #2: http://blog.marcocantu.com

There's no crash, but lots of warnings and assertions in the console. Marco, sorry that I send you on a "wild goose chase" with the crash idea. Thanks for the diligence on this bug.
Also, I don't get the missing content when JAWS is not running. So it sounds like the same bug.
This can probably be reduced even further.
The size of the initial window matters. What ever doesn't fit is not loaded into JAWS.

The smaller testcase file is breaking when I run it with Window-Eyes, and nothing gets loaded at all.
Also, you might need to save the testcase file on your hard drive for it to work.
This fixes the first part -- we shouldn't be returning early on content appends if the accessible hierarchy is already partially filled up. This was supposed to exactly duplicate a similar optimization in nsDocAccessible::InvalidateCacheSubtree().

The second part of the bug must be that we're either firing doc load events at the wrong time, or not at all. I'll deal with that next.

But this part is certainly incorrect and needs fixing.
Assignee: surkov.alexander → aaronleventhal
Status: NEW → ASSIGNED
Attachment #278842 - Flags: review?(ginn.chen)
I think that this fix is actually all we need, but I'm having trouble testing it with JAWS because of another bug I'm experiencing.
Same here: With the build compiled from sources, my JAWS also does not have a virtual PC cursor any more.
Attachment #278842 - Flags: review?(ginn.chen)
Attachment #278842 - Flags: review+
Attachment #278842 - Flags: approval1.9?
Marco, that must be a different bug. It might only affect debug builds.
Now that I fixed the other bug I can see this fix really works!
Attachment #278842 - Flags: approval1.9? → approval1.9+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
It does indeed! Would this perhaps be a candidate to land on Firefox 2.0.0.7 or later as well? The blog.marcocantu.com site at least is broken in Firefox 2 as well when JAWS is running, and who knows what other pages might be affected! What do you think?
The fix was actually a reversal of a change on August 5.

Our code in this area is completely different so the underlying causes for the problems in Firefox 2 are different.

We won't be able to easily port it, and we can't split our efforts away from Firefox 3 right now.
You need to log in before you can comment on or make changes to this bug.