Closed Bug 480697 Opened 11 years ago Closed 10 years ago

[SeaMonkey] mochitest-a11y: test_name.xul fails now: "... combobox list ... toolbaritem_textbox ..."

Categories

(Core :: Disability Access APIs, defect)

x86
Windows 2000
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- ?
status1.9.1 --- ?

People

(Reporter: sgautherie, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [test disabled on 1.9.1])

Attachments

(1 file)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090211 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/319799933481
 +http://hg.mozilla.org/comm-central/rev/...)

(No bug reported.)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090223 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/f6cdd2d6a9ea
 +http://hg.mozilla.org/comm-central/rev/720d3a1ea63d)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090228 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/f7f62131998d
 +http://hg.mozilla.org/comm-central/rev/7ea34ef19dc4)
{
...
984 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_name.xul | The last child of autocomplete textbox 'toolbaritem_textbox' should be dropmarker. - got 114, expected 43
985 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_name.xul | Wrong name for dropmarker of autocomplete textbox 'toolbaritem_textbox'. - got null, expected "ooospspss"
...
}

I would (wildly) guess that fixing bug 455886 "revealed" this,
which might be due to SeaMonkey not using the same "autocomplete" code as Firefox !??
Flags: wanted1.9.2?
Serge, could you say me how can I get trunk version of seamonkey? I have local comm-central repository, when I run "python client.py checkout" then it get updates from mozilla-1.9.1 repo instead of mozilla trunk repo.
Afaik, c-c doesn't "support" m-c yet,
though there are TB/m-c boxes, but I don't know how they did it.

So I would suggest this:
1) Rename your comm-central/mozilla (m-1.9.1) repository directory.
2) Check out m-c (as if you wanted to build Firefox), if you don't have one already.
3) Move/link your m-c repo dir from comm-central/mozilla.
4) Build SeaMonkey as usual.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090322 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/8d2c566f3256
 +http://hg.mozilla.org/comm-central/rev/573fb4c0ec8b)

Not sure when, but the first error changed:
{
905 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_name.xul | Wrong role for  'panel node' , role: nothing! - got 114, expected 43
906 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_name.xul | Wrong name for dropmarker of autocomplete textbox 'toolbaritem_textbox'. - got null, expected "ooospspss"
}
Ftr, a11y suite is now run on Linux and Windows SM 2.0 tinderboxes,
but "Makefile:113: test_nsIAccessible_name.xul temporarily disabled" there.
{
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090518 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/a7c0b3588242
 +http://hg.mozilla.org/comm-central/rev/6786ebf24275 + bug 493008 patches)

598 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_name.xul | Wrong role for [ 'panel node' , role: combobox list]! - got 114, expected 43
599 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_name.xul | Wrong name for dropmarker of autocomplete textbox 'toolbaritem_textbox'. - got null, expected "ooospspss"
}
Summary: [SeaMonkey] test_nsIAccessible_name.xul fails now: "... autocomplete textbox ..." → [SeaMonkey] mochitest-a11y: test_name.xul fails now: "... combobox list ... toolbaritem_textbox ..."
Whiteboard: [test disabled on 1.9.1]
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090711 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/47bfcd275ede
 +http://hg.mozilla.org/comm-central/rev/291cbe3374b9)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20091218 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)

(Bug still there.)
Blocks: a11ytestdev
Firefox textbox@type="autocomplete" has @enablehistory="true" attribute, Seamonkey's version has @disablehistory="true". Therefore autocomplete dropmarker is hidden and isn't accessible which makes test to fail.

Attributes defined in source:
id="toolbaritem_textbox" flex="1" type="autocomplete" enablehistory="true"

Actual attributes in Seamonkey:
sizetopopup="pref" timeout="50" maxrows="5" showpopup="true" disablehistory="true" disableKeyNavigation="true" userAction="none" id="toolbaritem_textbox" flex="1" type="autocomplete" enablehistory="true"

Actual attributes in Firefox
id="toolbaritem_textbox" flex="1" type="autocomplete" enablehistory="true" sizetopopup="pref"

Do you have any idea why seamoney's and firefox's autocomplete widgets have different attributes if they have the same binding (general/content/textbox.xml@autocomplete)?
They don't, SeaMonkey's (and Thunderbird's) binding lives in chrome://global/content/autocomplete.xml, while toolkit's binding lives in chrome://global/content/widgets/autocomplete.xml, but if it's a problem, just override the CSS and it should work. (Thunderbird actually does this somewhere, because it wants one binding in the Compose window and another somewhere else.)
Attached patch patchSplinter Review
since we don't test accessible tree here, we test accessible name computation for anonymous content then it doesn't matter what content we should test. I changed dropmarker to textbox, it works in Firefox and Seamonkey both.
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #423980 - Flags: review?(marco.zehe)
Attachment #423980 - Flags: review?(marco.zehe) → review+
Comment on attachment 423980 [details] [diff] [review]
patch

Don't we also want to test the drop marker again? You're completely removing that test and replacing it with the textbox test. I'm OK if that fixes things for both SeaMonkey and FF, but am wondering what we want to do with the drop marker.
(In reply to comment #11)
> (From update of attachment 423980 [details] [diff] [review])
> Don't we also want to test the drop marker again? You're completely removing
> that test and replacing it with the textbox test. I'm OK if that fixes things
> for both SeaMonkey and FF, but am wondering what we want to do with the drop
> marker.

Yes, we should but autocompletes have strange accessible trees which prevents me to write a test, I mean I'm not happy to make tests for things I'm not sure with.
If you really want the dropmarker, try disablehistory="false".
(In reply to comment #13)
> If you really want the dropmarker, try disablehistory="false".

Ok, thanks. But since we don't test accessible tree here then it doesn't matter whether we test text field or dropmarker. I think we need to have separate tests for the tree tests like Marco said, one test for toolkit's autocomplete, another one for seamonkey's version.
Fine with me, let's get this one landed and deal with those different autocompletes in one or two followup bugs.
landed on 1.9.3 - http://hg.mozilla.org/mozilla-central/rev/5e3ff51d6659
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to comment #15)
> Fine with me, let's get this one landed and deal with those different
> autocompletes in one or two followup bugs.

I filed bug 543462.
Blocks: 543462
status1.9.1: --- → ?
status1.9.2: --- → ?
Flags: wanted1.9.2?
Target Milestone: --- → mozilla1.9.3a1
Flags: in-testsuite+
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20100203 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)

V.Fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.