Closed Bug 763461 Opened 12 years ago Closed 11 years ago

Mozmill tests for cut-off elements should not report failure for scrollable direction

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set
normal

Tracking

(firefox22 fixed, firefox23 fixed, firefox24 fixed, firefox25 fixed, firefox-esr17 fixed)

RESOLVED FIXED
Tracking Status
firefox22 --- fixed
firefox23 --- fixed
firefox24 --- fixed
firefox25 --- fixed
firefox-esr17 --- fixed

People

(Reporter: whimboo, Assigned: andrei)

References

()

Details

(Whiteboard: [mozmill-l10n][mentor=whimboo][lang=js][lib])

Attachments

(4 files, 2 obsolete files)

Our Mozmill l10n tests have been shown that there are some elements which are cut-off due to the localization. The results of the test you can find here:

http://mozmill-ci.blargon7.com/#/l10n/report/ee284dfa9d664754a65676abbc060a2d

Details: 	

    Node is cut off by 10 px at the bottom: listitem#en-us. Parent node: listboxbody[rows=6][xbl:inherits=rows,size,minheight]
Hi Henrik,

How would I find where I should correct this?
CC'ing Axel who was helping with this feature. I agree that this information is not that helpful when looking at the plain text results. The screenshots should be more helpful but those are not available yet. I'm working at least at the next step here: https://github.com/mozilla/mozmill-ci/issues/108

I could try to find those screenshots for this locale.
Attached image screenshot
That's also the same listbox for the ve locale.
The screenshots do really help.

Not important for this locale as it was a cleanup on my side that triggered a build.  But thought I'd anticipate this for the other teams that are live and active.

Some OCR on that could make for some searchable strings to get us to the right page.  I'm dreaming ;)
Increasing <!ENTITY window.width "30em"> in tn/browser/chrome/browser/preferences/languages.dtd will help.

Sadly, I don't know where the height of that dialog is coming from.
I actually think this one is a false positive.  The list is just longer for tn then normal I think.
Looks like that we should exclude list/tree items in that case?
So I agree. I can reproduce it with an en-US locale by just adding more languages to the accepted languages list.

So it looks like that we should check first if the direction is scrollable, if not we can perform those tests. Otherwise we should return early. Axel, does that sound ok to you?
Assignee: dwayne → nobody
Component: tn / Tswana → Mozmill Tests
Product: Mozilla Localizations → Mozilla QA
QA Contact: dwayne → mozmill-tests
Summary: Elements cut-off in preferences dialog for tn locale → Mozmill tests for cut-off elements should not report failure for scrollable direction
Whiteboard: [mozmill-l10n] → [mozmill-l10n][lib]
Whiteboard: [mozmill-l10n][lib] → [mozmill-l10n][mentor=whimboo][lang=js][lib]
Blocks: 763470
Assignee: nobody → andrei.eftimie
Attached patch Patch v1 (obsolete) — Splinter Review
I've removed richlistbox items with a vertical orient, which targets only the failed test.
We get a green testrun on OSX and Windows:
http://mozmill-crowd.blargon7.com/#/l10n/report/c8094a822ef568b588c5eddaca81bdf4
http://mozmill-crowd.blargon7.com/#/l10n/report/c8094a822ef568b588c5eddaca85e9a4

I've separately attached an unskip patch because we still fail on Linux (seems to be some other cause):
http://mozmill-crowd.blargon7.com/#/l10n/report/c8094a822ef568b588c5eddaca815833

Apply both patches to be able to run the test.
The unskip patch should not land yet, as we should probably resolve the Linux problems first.
Attachment #740220 - Flags: review?(andreea.matei)
Attached patch unskip (obsolete) — Splinter Review
Comment on attachment 740220 [details] [diff] [review]
Patch v1

Review of attachment 740220 [details] [diff] [review]:
-----------------------------------------------------------------

::: lib/localization.js
@@ +99,5 @@
>    var parent = childBox.parentBox;
>  
> +  // skip for vertical richlistbox items
> +  if (childBox.element.nodeName === "richlistbox" &&
> +      childBox.element.orient === "vertical") {

There are various kinds of elements which have scrollbars. So we cannot exclude richlistbox only. Also elements can have horizontal scrollbars. So this approach will not work.

scrollHeight or something similar might help:
https://developer.mozilla.org/en-US/docs/DOM/element.scrollHeight
Attachment #740220 - Flags: review?(andreea.matei) → review-
Status: NEW → ASSIGNED
Attached patch patch v3Splinter Review
I've fixed the issue by using offsetWidth and offsetHeight instead of width and height.

The l10n crop test passes on all platforms:
OSX: http://mozmill-crowd.blargon7.com/#/l10n/report/5aa1ca5e7015e3740d269dc9472931a6
Linux: http://mozmill-crowd.blargon7.com/#/l10n/report/5aa1ca5e7015e3740d269dc947298fcd
Windows: http://mozmill-crowd.blargon7.com/#/l10n/report/5aa1ca5e7015e3740d269dc94729c965
Attachment #740220 - Attachment is obsolete: true
Attachment #740221 - Attachment is obsolete: true
Attachment #774533 - Flags: review?(andreea.matei)
Blocks: 763638
Comment on attachment 774533 [details] [diff] [review]
patch v3

Review of attachment 774533 [details] [diff] [review]:
-----------------------------------------------------------------

Landed:
http://hg.mozilla.org/qa/mozmill-tests/rev/14d962b72438 (default)

We will need backport on this in order to have the l10n tests fixed.
Attachment #774533 - Flags: review?(andreea.matei) → review+
I wouldn't backport this for all branches but aurora only. Reason is that we only run l10n tests on that branch. But if it turns out that the patch applies cleanly, I'm open to even backport it further. Lets get this into aurora, so that we can re-enable the test.

Btw. this patch should not have been re-enabled the test. I'm fairly sure we have a bug open which disabled the test. Also the manifest file hasn't been taken care of.
Attached patch reskip followupSplinter Review
reskip followup patch

As discussed we'll unskip the test in bug 741301
Attachment #775666 - Flags: review?(andreea.matei)
Comment on attachment 775666 [details] [diff] [review]
reskip followup

Review of attachment 775666 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry, my mistake here. Landed:
http://hg.mozilla.org/qa/mozmill-tests/rev/e20b71e03c74 (default)
Attachment #775666 - Flags: review?(andreea.matei) → review+
Attached patch patch v3.1Splinter Review
Applies cleanly an all branches. 
(contains fix, test still skipped)
Attachment #775672 - Flags: review?(andreea.matei)
Ok, so lets get this backported to aurora immediately, and the test enabled. Andrei, I assume you have tested the patch with various locales also with a RTL one?
Yep, works fine on .ar which is a RTL language
Comment on attachment 775672 [details] [diff] [review]
patch v3.1

Review of attachment 775672 [details] [diff] [review]:
-----------------------------------------------------------------

Great. Andrei tested all branches and it applied cleanly so here we have:

http://hg.mozilla.org/qa/mozmill-tests/rev/da282053b9bf (aurora)
http://hg.mozilla.org/qa/mozmill-tests/rev/81927d0b853b (beta)
http://hg.mozilla.org/qa/mozmill-tests/rev/e482db7a858a (release)
http://hg.mozilla.org/qa/mozmill-tests/rev/6d27262378b1 (esr17)

Lets get the test enabled now.
Attachment #775672 - Flags: review?(andreea.matei) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: