Closed
Bug 614948
Opened 14 years ago
Closed 8 years ago
Missing identifiers for anonymous elements in test results
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: Aleksej, Assigned: adriank)
References
Details
(Whiteboard: [MozmillTestday])
Attachments
(1 file)
2.06 KB,
patch
|
whimboo
:
review-
|
Details | Diff | Splinter Review |
* Mozmill 1.5.1 * Firefox-eo.4.0b8pre.20101126030319.Linux * http://hg.mozilla.org/qa/mozmill-tests/file/9ece7a033bfe/firefox/l10nTests/testCropped/test1.js gives this for the script permissions setup window: fail :: jum.assert function: jum.assert value: false comment: Node is cut off at the right: anonymous node. Parent node: anonymous node
Comment 1•14 years ago
|
||
This is mostly a missing feature of the l10n API or DOMWalker. For anonymous elements we should try to get the anonid or another property, you could use to identify the element.
Blocks: 562084
OS: Linux → All
Hardware: x86 → All
Summary: Mozmill test l10nTests/testCropped/test1.js should output more information (anonid or class) on anonymous nodes → Missing identifiers for anonymous elements in test results
Whiteboard: MozmillTestday → [MozmillTestday]
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #0) > gives this for the script permissions setup window: Actually it was for some other window.
Assignee | ||
Comment 3•14 years ago
|
||
Added a check for the anonid property. This patch also makes the access keys tests use the _reportNode() function, so we don't end with "undefined" results.
Comment 4•14 years ago
|
||
Comment on attachment 500690 [details] [diff] [review] patch v1 > function _reportNode(node) { > if (node.id) { > return "id: " + node.id; > } else if (node.label) { Please use cuttling formatting here. See our coding styles. It will make it much better readable. > return "label: " + node.label; > } else if (node.value) { > return "value: " + node.value; >+ } else if (node.anonid) { >+ return "anonid: " + node.anonid; I would say that we should move the anonid right after the id case. It's more important as the label and value. > } else if (node.hasAttributes()) { >- var attrs = "node attributes: "; >+ var attrs = "node-attributes: "; > for (var i = node.attributes.length - 1; i >= 0; i--) { > attrs += node.attributes[i].name + "->" + node.attributes[i].value + ";"; > } > return attrs; > } else { If everything goes worse we also have the properties on an object we could iterate through. > return "anonymous node"; It's not an anonymous node in that case. It's more an 'unknown' node. Haven't tested yet, but looks good. And I think with those changes made, it should be ready. Please think of exporting the patch.
Attachment #500690 -
Flags: review?(hskupin) → review-
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > Comment on attachment 500690 [details] [diff] [review] > patch v1 > > I would say that we should move the anonid right after the id case. It's more > important as the label and value. From a localizer-perspective, I'd say the label is most important - most localizers can do more with it than with an anonid. The value is less important, right.
Comment 6•14 years ago
|
||
Well, how often it happens that labels are used multiple times? I think it would even better if we instead show the entity name, or?
Assignee | ||
Comment 7•13 years ago
|
||
(In reply to comment #6) > Well, how often it happens that labels are used multiple times? Often, but not often in the same window/dialog. > I think it would even better if we instead show the entity name, or? It would be definitely better, but I don't know of any way to get the entity ID out of the DOM...
Comment 8•13 years ago
|
||
(In reply to comment #7) > > I think it would even better if we instead show the entity name, or? > It would be definitely better, but I don't know of any way to get the entity ID > out of the DOM... Axel, do you know a way?
Comment 9•13 years ago
|
||
There is no way to get back to the entity. There might be value with going up the DOM parent chain at some point, but that depends on the use case. Also, I think we should really say how much is cut off. That'd help the cases where it's just a line due to some layout bug.
Comment 10•8 years ago
|
||
Mozmill tests are no longer in use. So closing this bug.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
QA Contact: hskupin
Resolution: --- → WONTFIX
Updated•5 years ago
|
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•