616876 - Add l10n tests for proxy configuration and clear private data settings dialogs

Status: RESOLVED WONTFIX

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[Pavel Cvrcek [:JasnaPaka]]

Attachment: Test result

Mozmill 1.5.1, latest Firefox 4.0 build

It looks like that test "firefox/l10nTests/testAccessKeys/test1.js" ignores GUI elements which are disabled. See screenshot which is attached. There you can see one duplicite accesskey which was detected correctly. But another one wasn't detected.

Compare  "_P_ort" and "_P_ro všechny protokoly používat tento proxy server"

It looks like that GUI elements which are disabled are ignored in detection. But in this dialog when I choose manual settings are both elements accessible.

Comment 1

[Adrian Kalla [:adriank]]

Ignoring disabled elements is a feature, not a bug. The reason is simple: access keys of disabled elements cannot collide with other access keys.

What can be done here, is to make the necessary changes to enable those elements and run the test again for that window - like it's already done for the "Custom" settings in the "Privacy" preferences pane.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sounds that this would be the best path to include checks for those accesskeys. Do we have other instances too? The network panel for the cache?

Comment 3

[Adrian Kalla [:adriank]]

Attachment: patch v1

Added a section for testing the rest of the proxy window.

Also added a section for testing the sanitize window opened from the privacy pane.

I guess there will be more elements that will have to be enabled to have them tested - I'd propose to create separate bugs for them, when such elements will be found.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Comment on attachment 500703 [details] [diff] [review]
patch v1

Test passed. Looks good. Duplicating an access key in the connection dialog now shows it as failure. The only downside is the reporting, which makes it hard to locate. But that's another bug.

ERROR | Test Failure: {"function": "jum.assert", "comment": "accessKey: x found in string's: [id: (id is undefined), label: (label is undefined)], [id: (id is undefined), label: (label is undefined)]", "value": false}

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Landed as:
http://hg.mozilla.org/qa/mozmill-tests/rev/7625f064b018 (default)
http://hg.mozilla.org/qa/mozmill-tests/rev/a115ac3f12f5 (mozilla1.9.2)

Adrian, next time please attach an exported patch. Thanks.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I had to backout this patch because it kills the testrun. On Windows the dialog under Privacy doesn't get opened, so the complete tests are failing.

Backed out:
http://hg.mozilla.org/qa/mozmill-tests/rev/a81cf84985e0 (default)
http://hg.mozilla.org/qa/mozmill-tests/rev/7bd6c22e6e31

Comment 7

[Adrian Kalla [:adriank]]

After spending some time on trying to reproduce it, I finally could do it on Firefox 4.0b9. But it works perfectly with Firefox 3.6.x and 4.0b6...

The problem is not this patch itself. The problem is, that for some unknown reason, on 4.0b9+ when unchecking the "Work always in private" option in the custom-setting of the Privacy prefpane, all the items that should be enabled, stay disabled. Interestingly, when re-doing the same steps Mozmill does manually, everything works as expected.
So in fact, because the elements stay disabled, we can't find any bugs (duplicated access keys) they have right now. 

I'll file a new bug for this and mark this one as dependent on it.
On the other side, as I couldn't reproduce the problem with Firefox 3.6, I guess we could re-enable this patch there.

Comment 8

[Mike Hoye [:mhoye]]

Hi, Andreea - can you confirm that you're still willing to mentor this bug?

Comment 9

[Andreea Matei [:AndreeaMatei]]

Yes, I am.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Mozmill is dead, WONTFIX the remaining bugs.