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

RESOLVED FIXED

Status

Mozilla QA
Mozmill Tests
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: adriank, Assigned: adriank)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

7 years ago
Created attachment 493404 [details] [diff] [review]
*ugly* patch which catches nodes hidden under object._buttons

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.
(Assignee)

Updated

7 years ago
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?
(Assignee)

Comment 2

7 years ago
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?
(Assignee)

Comment 4

7 years ago
Created attachment 500459 [details]
test case for parent-less children

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.
(Assignee)

Comment 5

7 years ago
Created attachment 500562 [details] [diff] [review]
proposed work-around

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+
(Assignee)

Comment 7

7 years ago
Created attachment 502902 [details] [diff] [review]
workaround-patch

(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
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.