GNOME Bugzilla – Bug 544122
Problems with downloading files with Firefox 3
Last modified: 2009-03-10 00:05:23 UTC
Christian reported on the Orca list: > I have noticed that when downloading files with Firefox and when the > file download is complete and I have set the download window to close > it is not possible to navigate a website with the tab key. Confirmed.
Created attachment 115100 [details] [review] revision 1 This patch does several things: 1. Adds logic to the Gecko toolkit's speech generator for links so that we indicate links which are also images. (The braille generator already seems to be doing the correct thing as-is.) 2. Removes code in onFocus() which forces focus on an image if what currently has focus is a link which contains an image. As best as I can tell, all that was accomplishing is causing us to speak the fact that the link was an image. We can do that via the speechgenerator change. Besides, images cannot receive focus, thus setting focus on the image merely causes us to grab focus on the link which had focus in the first place -- and then to have to ignore the event we just triggered. 3. Removes code which intentionally did not grab focus on a link if the link contained an image AND other text. We see this when arrowing around ftp sites within Firefox. Arrowing should be grabbing focus on the links for the files, but currently is not. The avoidance code was something I added as part of bug 511118. It seems that whatever had been causing that issue was fixed on the Firefox side of things: Using both Firefox 3 and Firefox 3.1 and the Orca revision just prior to the checkin for bug 511118, I can no longer reproduce that issue. 4. Adds a check to onLocusOfFocus changed to see if we really are still loading a document. What is at the heart of this bug is this: When you follow a link for a download, Firefox issues an object:state-changed:busy event (detail1 == 1) to let us know loading has started. It never issues a subsequent event to tell us that loading has finished. We intentionally are not speaking focus changes when the document frame is busy because we want to minimize chattiness when a page is loading. We should either be getting the subsequent event or we shouldn't be getting the first one (because a new page isn't actually loading). Either way, that's a Mozilla bug filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=446469 Still, it's one we can work around. I'm still updating the regression tests for 3.1 goodness, but running the tests I have on my box atm indicates no regressions resulting from this patch. Already pylinted. Mike please test.
Created attachment 115115 [details] [review] revision 2 Oops. Needed to do a null check in case we did not have a document frame (e.g. tbird message list). Sorry Mike! Please try this one. Pylinted. Will need to re-run the regression tests to be safe.
When tabbing to the document area on a bug do we really want to say "home link image" You actually have to tab twice to be able to click the link.
> When tabbing to the document area on a bug do we really want to say "home link > image" You actually have to tab twice to be able to click the link. Really? I don't. When the page loads and I press Tab, Orca (with this patch) says "home link image." If I then press Enter, I'm taken to bugzilla.gnome.org (i.e. the bugzilla home page).
BTW, the above is the case for both FF3.0 and FF3.1.
When doing this are you tabbing from the address bar or the top of the page? The result I reported was from the address bar.
The address bar here as well. A debug.out would be helpful I guess.
Regardless, this bug here is about our being silent for ever more when a file has been downloaded. It also fixes the issue of wanting to arrow amongst items when browsing an FTP site and have focus go to the link you're on (or would be on were we not preventing it). Both of these are pretty serious issues I think. Unless the behavior you are seeing as a side effect is completely unacceptable, perhaps we could address it in the bug we have open for what happens when focus is given to the document frame?
Aha, I was able to reproduce it once. It looks like we speak the first line if we don't have a caret context. I must have already caused a caret context to be created by pressing Control+Home. Anyhoo.... If we present the first line when the document frame has focus, you can start arrowing down without missing the first line. If this is not the behavior you want, we can change it, but again, let's do that in the bug you've opened for that issue.
Sounds good to me.
Okie dokie. Thanks! I've committed the patch to trunk. Marking this as pending. Let's work on the other issue in bug 544197.