Closed
Bug 642626
Opened 13 years ago
Closed 9 years ago
mochitest-a11y: tree/test_tabbrowser.xul triggers a visual "tabbrowser" issue
Categories
(SeaMonkey :: Tabbed Browser, defect)
Tracking
(blocking-seamonkey2.1 -)
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
blocking-seamonkey2.1 | --- | - |
People
(Reporter: sgautherie, Unassigned)
References
()
Details
(Keywords: access)
1) Run this test with Firefox. 1r) You see "Menu" with the 2 expected tabs just below it :-) 2) Run this test with SeaMonkey. 2r) The in-between 'tabs' element is shown too :-( Code is: { <tabs id="tabbrowser-tabs" class="tabbrowser-tabs" tabbrowser="tabbrowser" setfocus="false"> <tab class="tabbrowser-tab" selected="true" fadein="true"/> </tabs> } I wonder whether this could allow to exploits or at least bad rendering. *** Neil: This test refers to bug 540389, and we might need to port http://hg.mozilla.org/mozilla-central/diff/3198c740b660/browser/base/content/tabbrowser.xml to add 'role="presentation"'. (though I didn't find an 'id="tabbrowser-tab"' binding to just copy&paste to...) Just in case, check whether bug 577762 might be related too. *** Alexander: I wonder whether this test should (be able to) catch this case? And how.
Comment 1•13 years ago
|
||
Firefox's tabbrowser changed so that it no longer contains its <tabs> element. Instead you have to explicitly define a <tabs> element and reference its id in the tabcontainer attribute. However the test appears to correctly reference the <tabs> element using the .tabContainer property which works on both tabbed browsers. The test would fail if it tried to test the tabbrowser's accessible tree though as that would be different.
Comment 2•13 years ago
|
||
Serge can you describe how to trigger whatever "visual issue" this is, outside of running that test. Without a way for a regular user to trigger this, blocking-
blocking-seamonkey2.1: ? → -
Comment 3•13 years ago
|
||
(In reply to comment #0) > *** Alexander: > > I wonder whether this test should (be able to) catch this case? And how. we care about widgets testing, from different angles so it doesn't hurt if the test checks in-between elements, in the other words check everything that's accessible what's related with this widget usage. But it sounds like it's rather just in case check than necessary one. by testAccessibleTree (several or one)?
Comment 4•9 years ago
|
||
Serge please reopen if this report is still valid, has value and can get some action.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•