Closed Bug 614949 Opened 14 years ago Closed 14 years ago

DOMWalker can't find nodes where the parents don't have them as children

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: adriank, Assigned: adriank)

References

Details

(Whiteboard: [mozmill-l10n][MozmillTestday])

Attachments

(2 files, 2 obsolete files)

During testing on Windows and Linux I noticed, that not all duplicated access keys were catch. After some debugging I've found out, that we have nodes in the tree which have a parent node, but that parent node does not list them as children, so they won't be found by the current DOMWalker.

The only case I've found for now is the "_buttons" object of "BrowserPreferences", which holds the "OK", "Cancel" and "Help" buttons for the Preferences window on Windows and Linux (and on Mac the "Help" icon of the subwindows of the Preferences window). 
To see the difference in the results, the attached ugly patch has to be applied. A good example to test is Polish Fx 4.0b6.

I'm not sure if "_buttons" is the only case, or if there are more ones. Knowing the reality, I guess it'll be the latter one. 
I still have to think how to solve it right... But one thing for sure: it'll require changes to the _walk-method.
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [mozmill-l10n] → [mozmill-l10n][MozmillTestday]
Can you please give a link to the appropriate line in the XUL file?
Comment on attachment 493404 [details] [diff] [review]
*ugly* patch which catches nodes hidden under object._buttons

http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/preferences.xml#575
Attachment #493404 - Attachment description: *ugly* patch which catches nodes hidden under node._buttons → *ugly* patch which catches nodes hidden under object._buttons
All those buttons are childNodes of the hbox. Not sure which parent do you mean in detail here?
A short test case showing that we can get from child-node through the parent-node to the grand-parent-node, but in case of _buttons, we can't go the other way around, as the grand-parent-node is missing the parent-nodes in the childNodes list.
Attached patch proposed work-around (obsolete) — Splinter Review
I'd propose, as long as no one finds a better solution, to use this work-around. Without checking the "node._buttons" object, we miss most of the existing duplicated access keys.
Attachment #493404 - Attachment is obsolete: true
Attachment #500562 - Flags: feedback?(hskupin)
Assignee: nobody → akalla
Status: NEW → ASSIGNED
Comment on attachment 500562 [details] [diff] [review]
proposed work-around

Looks great and works great! We even have duplicated access keys in the en-US locale! Can you please create a final patch via export?
Attachment #500562 - Flags: feedback?(hskupin) → review+
Attached patch workaround-patchSplinter Review
(In reply to comment #6)
> Comment on attachment 500562 [details] [diff] [review]
> proposed work-around
> 
> Looks great and works great! We even have duplicated access keys in the en-US
> locale! Can you please create a final patch via export?

done
Attachment #500562 - Attachment is obsolete: true
Attachment #502902 - Flags: review?(hskupin)
Attachment #502902 - Flags: review?(hskupin) → review+
Landed as:
http://hg.mozilla.org/qa/mozmill-tests/rev/064337b98c94 (default)
http://hg.mozilla.org/qa/mozmill-tests/rev/c3f054b43c4e (1.9.2)

I will file new bugs for the duplicated access keys in en-US. Woot!
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: