If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

mochitest-a11y: tree/test_tabbrowser.xul triggers a visual "tabbrowser" issue

RESOLVED INCOMPLETE

Status

SeaMonkey
Tabbed Browser
--
critical
RESOLVED INCOMPLETE
7 years ago
2 years ago

People

(Reporter: sgautherie, Unassigned)

Tracking

({access})

Trunk
x86
Windows 2000
access

Firefox Tracking Flags

(blocking-seamonkey2.1 -)

Details

(URL)

(Reporter)

Description

7 years ago
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

7 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.
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

7 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)?

Updated

6 years ago
Keywords: access
Serge please reopen if this report is still valid, has value and can get some action.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.