GNOME Bugzilla – Bug 515571
FF3 form field structural navigation should handle form fields that are not in forms
Last modified: 2008-07-22 19:33:47 UTC
Please describe the problem: clean orca trunk, ff3.04beta as of this morning. visiting www.google.com submit "orca" as a search. on result page, we can happily browse the page, previous/next heading etc. but when pressing orcakey+tab to get back to the search box again, the search wrapps around and fails to find the searchbox. Attached is the debug file. Steps to reproduce: Actual results: searchbox is missed Expected results: Does this happen every time? yes Other information:
Created attachment 104840 [details] debug.out
Okay, here's the deal: 1. Google's markup of the page in question is such that the form controls are not officially part of the form. This is not *just* in the accessible hierarchy; it's the case according to the DOM Inspector. <grumble>Crappy markup</grumble> On the main google page, the form controls are officially part of the form. That's the difference. In light of this: 2. I could certainly file a general bug against FF (as opposed to an a11y bug, because the accessible hierarchy seems to match the official hierarchy). However, given that we're in the late stages of the game where everything must be blessed by one holy person per religion per continent for inclusion into 1.9, and given that the problem is due to poor markup rather than an actual FF bug, I'm not sure how good our chances are for inclusion into FF3. Granted it's Google as opposed to some site no one's heard of... So maybe it would get in. <shrugs> However: 3. Ignoring this particular bug for a moment and looking more broadly, not all objects which one might consider a "form field" live inside actual forms. Sometimes you come across controls just kinda floating there that have associated javascript to perform the appropriate formy tasks. Unfortunately: 4. Our definition of "form field" is a field inside a form. See: http://bugzilla.gnome.org/show_bug.cgi?id=423427 comments 8 through 10. Had I only known back then what I know now.... <grin> So gang, what shall we do? Revise our definition of what is a form field to essentially be an enumeration of the type of objects we expect to find in forms, or file a FF bug and block this one against it?
(In reply to comment #2) > hierarchy; it's the case according to the DOM Inspector. <grumble>Crappy > markup</grumble> Yech. > 2. I could certainly file a general bug against FF (as opposed to an a11y bug, > because the accessible hierarchy seems to match the official hierarchy). What would the bug suggest? Would it be to munge the DOM to accommodate poor markup? > 3. Ignoring this particular bug for a moment and looking more broadly, not all > objects which one might consider a "form field" live inside actual forms. > Sometimes you come across controls just kinda floating there that have > associated javascript to perform the appropriate formy tasks. Yep. :-( > 4. Our definition of "form field" is a field inside a form. See: > http://bugzilla.gnome.org/show_bug.cgi?id=423427 comments 8 through 10. Had I > only known back then what I know now.... <grin> > > So gang, what shall we do? Revise our definition of what is a form field to > essentially be an enumeration of the type of objects we expect to find in > forms, or file a FF bug and block this one against it? I think we should challenge authors of crappy pages to produce good markup. That's an uphill battle, though, especially in the wild web. I'm not what the specifics of the FF bug would be. But, I'm going to guess they will not fix it for 1.9, whatever the bug may be. So, I think we will need to provide logic on our side.
Created attachment 105650 [details] [review] revision 1 This redefines isFormField() so that we look at object roles rather than (official) containment within an (official) form. Pylinted and regression tested and seems to solve the problem reported in this bug.
Thanks Joanie, works well here. bug fixed. Ive been away, was wondering if you could please point me to stuckage bugs, so that I could keep my eye on them.
Works great. thanks
orca rev 3613, ff3 as of today. unintended consequence: vanilla rev 3613 quick search works fine. applying patch 105650 quick search doesnt work anymore.
Thanks Jon. More specific steps to reproduce would be helpful.
the usual way for me to find the list of orca bugs (yes not bookmarked) address: http://live.gnome.org/Orca once page loads: /bugs landing on: "The complete list of work to do, including bugs and feature requests, along with known problems in other components, is maintained in" then orca+tab across to: "Bugzilla" link doing the same with patch applied i get no output after /bugs using up and down arrows, the focus seems to be the same as before the quick search.
gotcha. Thanks. I have a guess just from looking at the code. Hopefully a new patch coming soon.
sorry ment orca+right arrow, not orca+tab
Created attachment 105666 [details] [review] revision 2 Jon please see if this solves it for you. Thanks!
solved, thank you :)
Retitling this bug to reflect the broader issue.
Patch committed. Moving to pending.