Closed Bug 712630 Opened 12 years ago Closed 12 years ago

Allow devs to change screen resolution in-tree so they can try larger screen resolutions

Categories

(Infrastructure & Operations Graveyard :: CIDuty, task, P2)

x86
Windows 7

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: armenzg, Assigned: armenzg)

References

Details

Attachments

(8 files, 5 obsolete files)

1.30 KB, patch
roc
: review+
Details | Diff | Splinter Review
52.10 KB, text/plain
Details
1.76 KB, patch
roc
: review+
Details | Diff | Splinter Review
3.15 KB, patch
joe
: review+
Details | Diff | Splinter Review
4.52 KB, patch
coop
: review+
armenzg
: checked-in+
Details | Diff | Splinter Review
381 bytes, patch
jmaher
: review+
armenzg
: checked-in+
Details | Diff | Splinter Review
1.96 KB, patch
jmaher
: review+
armenzg
: checked-in+
Details | Diff | Splinter Review
2.35 KB, patch
coop
: review+
armenzg
: checked-in+
Details | Diff | Splinter Review
In bug 702504 we discovered that after attaching a dongle we can have the expected screen resolution to run accelerated reftests.

Before IT and I can deploy the dongles we need someone to fix the tests.
If these are not fixed there's nothing that IT/releng can do.
We can loan a machine with a dongle for this to be fixed if needed.

http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1323935060.1323937392.30220.gz&fulltext=1
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/635373-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/635373-2.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/635373-3.html | image comparison (==)
Hi,
We need this fixed so IT and releng can install the dongles and get back the correct screen resolution.

Can I please have a taker?
Blocks: 710233
No longer blocks: 702504
Assignee: nobody → bas.schouten
Thanks for taking the bug!

Is the plan to try to fix them? or to disable them while we figure it out?

I would like to know the timeline just to give enough heads up to IT on when to add the dongles and to take advantage of any other downtimes scheduled in the next weeks.
Bas: ping

Having a timeline will help IT and us to allocate resources.
This quarter is going to be a super busy quarter for IT with the colo move. This means that if we get this resolved earlier we will have higher chances of finding a slot or a downtime to squeeze this in.

Thanks!
I'll write a patch for this failure this week. I know what causes it.
Hi, Bas, just checking to see if there's been any progress on this.  We're attempting to determine when a tree closure will need to happen to schedule the hardware work that depends on this fix.  Thanks!
So, I've decided to mark these tests random. The reason for these failures is that in some situations we get a transparent layer, we then draw the rectangular bounds of the visible region and any edges of the visible region's rects inside the bounds of the visible region will get 'anti-aliased' by interpolation. When we have an opaque surface D3D10 will draw strictly the visible region rather than promoting the entire layer to be transparent (and making text drawing different). When doing this any inner edges will actual become boundaries of a quad and will become aliased. I think for now this behaviour is acceptable since our outer edges are aliased anyway.

I'd rather mark these tests random than change behavior at this point. We should consider the behavior in a separate bug and make it consistent across layer managers to the extent that we can.
Attachment #592163 - Flags: review?(roc)
How about making them fuzzy-if?
I'm not sure how fuzzy matching works? Note the per pixel differences here can be quite significant (up to 50% coverage). Although the absolute number of pixels is relatively small.
Comment on attachment 592163 [details] [diff] [review]
Mark several tests random when D2D is used.

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

ok
Attachment #592163 - Flags: review?(roc) → review+
https://hg.mozilla.org/mozilla-central/rev/c0fa1e61c619
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Thanks! I will test it in the next day on our pre-production systems to see that we're good to go.
It seems that we have 2 perma-oranges for both debug and opt reftests:
https://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1328146765.1328149807.19234.gz&fulltext=1
https://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1328146765.1328149807.19234.gz&fulltext=1

REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/718521.html | image comparison (==)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached file 2 failling tests
Here are the differences of the images.

bas, we can get you access to one of the two slaves so you can figure it out.
It won't take us much time to set it up for you.
Bas, joe: ping

This is very important as we want to get back to test with accelerated graphics.
Roc: One of these is a subpixel AA vs. non-subpixel AA difference, that's 1051 differing pixels, so we should probably just disable that with D3D10 layers.

The other is a subtle corner AA difference, 51 differing pixels, we could fuzzy-match that. Do you agree with that?
I think we should just use fuzzy in both cases.
Armen, can we land this and get the accelerated reftests turned on ASAP? That way we can be sure they'll stay green.
If we land it on the try server I can test it on staging.
Once that shows fruitful I will coordinate with IT for a downtime next week to attach all the dongles.
https://hg.mozilla.org/integration/mozilla-inbound/rev/572b054e8c40

I didn't look on try? Can I get the data from the m-i run?
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #20)
> If we land it on the try server I can test it on staging.
> Once that shows fruitful I will coordinate with IT for a downtime next week
> to attach all the dongles.

I just pushed m-i to try: https://tbpl.mozilla.org/?tree=Try&rev=8a2518e5f181
(In reply to Joe Drew (:JOEDREW!) from comment #23)
> (In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment
> #20)
> > If we land it on the try server I can test it on staging.
> > Once that shows fruitful I will coordinate with IT for a downtime next week
> > to attach all the dongles.
> 
> I just pushed m-i to try: https://tbpl.mozilla.org/?tree=Try&rev=8a2518e5f181

If what Bas pushed to m-i (which is now on m-c) is the same as on try then we don't need the try build.

Mind cancelling the try build IIUC?
Thanks Joe!

I bring bad news :( I am going to need several oranges to be fixed.

I am very sorry but I believe I only re-triggered reftests 2 weeks ago and this time I triggered everything. I might have discovered now oranges that might have been introduced in the last 2-3 months.

FTR I am testing this on staging:
https://tbpl.mozilla.org/?jobname=WINNT%206.1&rev=31fa580e684c

There might actually be more oranges than the initial four suites since I had two slaves but one of the them was misbehaving (I pulled it out).
I am triggering now every jobs on talos-r3-w7-053 for the same changeset and see if there are more oranges.

This is the initial set of oranges:
* Rev3 WINNT 6.1 mozilla-central debug test mochitest-other [1] (leak)
* Rev3 WINNT 6.1 mozilla-central debug test reftest [2]
* Rev3 WINNT 6.1 mozilla-central opt test mochitests-3/5 [3]
* Rev3 WINNT 6.1 mozilla-central opt test reftest [4]

[1]
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329462846.1329466407.13165.gz&fulltext=1

[2]
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329466489.1329469660.19461.gz&fulltext=1
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==)

[3]
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329445148.1329445602.4968.gz&fulltext=1
19788 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/text/tests/test_bug600570.html | Pasting and setting the value directly should result in the same rendering

[4]
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551.1329445064.3528.gz&fulltext=1
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==)
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #26)
> [4]
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551.
> 1329445064.3528.gz&fulltext=1
> REFTEST TEST-UNEXPECTED-FAIL |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-
> 1.html | image comparison (==)

This one's interesting, 1051 difference but it reports only tolerating 52, my patch made it:

fuzzy-if(d2d,1,1051)

is that wrong somehow?


> REFTEST TEST-UNEXPECTED-FAIL |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-
> overflow/xulscroll.html | image comparison (==)

Tiny subpixel AA diff, I suspect we can just fuzzy-if.

> REFTEST TEST-UNEXPECTED-PASS |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/
> preserve3d-1a.html | image comparison (==)

Unexpected pass! I can live with that :).
What is the status with this? Thanks in advance!
Can someone answer my first question? :)
Are you referring to comment 27? is that for joe/roc? me?
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #30)
> Are you referring to comment 27? is that for joe/roc? me?

I'd be perfectly happy with anyone who knows the answer! :)
joe/roc: can you please see if you can help Bas with his question in comment 27?
I'm slammed right now, and roc's on vacation. 

Timothy, can you help us out with comment 27?
(In reply to Bas Schouten (:bas) from comment #27)
> (In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment
> #26)
> > [4]
> > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551.
> > 1329445064.3528.gz&fulltext=1
> > REFTEST TEST-UNEXPECTED-FAIL |
> > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-
> > 1.html | image comparison (==)
> 
> This one's interesting, 1051 difference but it reports only tolerating 52,
> my patch made it:
> 
> fuzzy-if(d2d,1,1051)
> 
> is that wrong somehow?

I think 'fuzzy-if(d2d,1,1051)' means tolerate upto 1051 pixels being different by at most 1 in any channel.

The log at http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551.1329445064.3528.gz&fulltext=1#err0 is saying that 1051 pixels differed, and the maximum difference in any channel in those pixels was 52.

So if you want to paper over this failure you want to increase the 1 to 52.

Looking at the images though it appears that the text is getting subpixel AA in the reference, but grey scale AA in the test.
(In reply to Timothy Nikkel (:tn) from comment #34)
> Looking at the images though it appears that the text is getting subpixel AA
> in the reference, but grey scale AA in the test.

I think we should still be able to get subpixel AA here, so if you go that route we should file a bug on this.
(In reply to Timothy Nikkel (:tn) from comment #35)
> (In reply to Timothy Nikkel (:tn) from comment #34)
> > Looking at the images though it appears that the text is getting subpixel AA
> > in the reference, but grey scale AA in the test.
> 
> I think we should still be able to get subpixel AA here, so if you go that
> route we should file a bug on this.

I suspect maybe normally both are greyscale. BasicLayers supplies subpixel AA a little less than the accelerated managers in theory. But regardless of that this is the reality our users are already on, I'd rather get the tests up and running for the current product than wait until we can fix underlying bugs.

If you think the missing subpixel-AA is a gfx problem let me know though!
Yeah, that sounds reasonable.
I filed bug 730215 for that.
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #26)
> Thanks Joe!
> 
> I bring bad news :( I am going to need several oranges to be fixed.
> 
> I am very sorry but I believe I only re-triggered reftests 2 weeks ago and
> this time I triggered everything. I might have discovered now oranges that
> might have been introduced in the last 2-3 months.
> 
> FTR I am testing this on staging:
> https://tbpl.mozilla.org/?jobname=WINNT%206.1&rev=31fa580e684c
> 
> There might actually be more oranges than the initial four suites since I
> had two slaves but one of the them was misbehaving (I pulled it out).
> I am triggering now every jobs on talos-r3-w7-053 for the same changeset and
> see if there are more oranges.
> 
> This is the initial set of oranges:
> * Rev3 WINNT 6.1 mozilla-central debug test mochitest-other [1] (leak)
> * Rev3 WINNT 6.1 mozilla-central debug test reftest [2]
> * Rev3 WINNT 6.1 mozilla-central opt test mochitests-3/5 [3]
> * Rev3 WINNT 6.1 mozilla-central opt test reftest [4]
> 
> [1]
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329462846.
> 1329466407.13165.gz&fulltext=1
> 
> [2]
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329466489.
> 1329469660.19461.gz&fulltext=1
> REFTEST TEST-UNEXPECTED-FAIL |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-
> 1.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-PASS |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/
> preserve3d-1a.html | image comparison (==)
> 
> [3]
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329445148.
> 1329445602.4968.gz&fulltext=1
> 19788 ERROR TEST-UNEXPECTED-FAIL |
> /tests/editor/libeditor/text/tests/test_bug600570.html | Pasting and setting
> the value directly should result in the same rendering
> 
> [4]
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551.
> 1329445064.3528.gz&fulltext=1
> REFTEST TEST-UNEXPECTED-FAIL |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-
> 1.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-FAIL |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-
> overflow/xulscroll.html | image comparison (==)
> REFTEST TEST-UNEXPECTED-PASS |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/
> preserve3d-1a.html | image comparison (==)


Soo, question about this, I'll be addressing this, but one thing comes to mind, mochitest should've not changed. They should've always been running accelerated as they don't care about screen size.

Did you not filter out random oranges perhaps? Especially since we have a failure in opt which isn't in debug reftests.
I will get back to you with fresh results tomorrow.
This is now finally working on staging again (I made few mistakes to trigger things).

I will have answers for mochitests tomorrow.

Are you being able to make progress on the reftests side?

For the next round I will keep the logs on bugzilla or people since the tbox logs are not available.
Bas, do you have everything you need to make progress?

It seems the mochitest were transient.

This is what we have now:
* Rev3 WINNT 6.1 mozilla-central debug test reftest [1]
* Rev3 WINNT 6.1 mozilla-central opt test reftes [2]
* Rev3 WINNT 6.1 mozilla-central opt test reftest-no-accel [3]

[1]
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1330478093.1330481225.22197.gz&fulltext=1
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==)

[2]
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1330442311.1330444709.18555.gz&fulltext=1
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/css-valid/select/select-required-multiple-invalid.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/css-valid/select/select-required-multiple-valid.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==)

[3]
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1330474067.1330476335.12610.gz&fulltext=1
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/abs-pos/auto-offset-inline-block-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2a.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2b.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2c.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2a.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2b.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613157-2.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/564991-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/579985-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/581317-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/ogg-video/encoded-aspect-ratio-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/webm-video/encoded-aspect-ratio-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | view-source:file:///c:/talos-slave/test/build/reftest/tests/parser/htmlparser/tests/reftest/bug482921-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01a.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01b.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01c.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01d.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==)
I placed the logs in here:
http://people.mozilla.com/~armenzg/bug712630
I'll have another look at this tomorrow, it looks like I've got the information I need here.
Any updates?
I just chatted with Bas and he will be looking into this today to mark them as random-if or fuzzy-if. This should get us going. Further investigation of why those failures are happening could come in a separate bug.

Bas asked me how come no-accel gets regressed if they are *not* accelerated.
I don't know why changing the resolution would affect those but let me put out the links and make explicit what gets called. This might help to point out if we are running anything incorrectly.

* For accelerated tests (which we know they are not - this bug tries to fix it) [1]:
'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' u'--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1331676785/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' 'reftest/tests/layout/reftests/reftest.list'
REFTEST INFO | WARNING: USE_WIDGET_LAYERS disabled
args: ['c:\\talos-slave\\test\\build\\firefox\\firefox.exe', '-no-remote', '-profile', 'c:\\users\\cltbld\\appdata\\local\\temp\\tmpr3k-bc/', '-reftest', 'c:\\talos-slave\\test\\build\\reftest\\tests\\layout\\reftests\\reftest.list']

* For *not* accelerated tests [2]:
'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' u'--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1331676785/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' '--setpref=gfx.direct2d.disabled=true' '--setpref=layers.accelerate-none=true' 'reftest/tests/layout/reftests/reftest.list'
args: ['c:\\talos-slave\\test\\build\\firefox\\firefox.exe', '-no-remote', '-profile', 'c:\\users\\cltbld\\appdata\\local\\temp\\tmp6yttpe/', '-reftest', 'c:\\talos-slave\\test\\build\\reftest\\tests\\layout\\reftests\\reftest.list']
REFTEST INFO | WARNING: USE_WIDGET_LAYERS disabled

The only difference I see is this (which makes sense IIUC):
'--setpref=gfx.direct2d.disabled=true' '--setpref=layers.accelerate-none=true'

I hope this can allow us to spot something that is being run incorrectly.

[1]
https://tbpl.mozilla.org/php/getParsedLog.php?id=10047030&tree=Firefox&full=1

[2]
https://tbpl.mozilla.org/php/getParsedLog.php?id=10047052&tree=Firefox&full=1
According to Bas, we're probably are *not* running non-accel properly.
He says we need "layers.acceleration.disabled=true".
This is instead of "--setpref=layers.accelerate-none=true".

Let's see what happens on staging with a slave with dongle and another without a dongle.
Whiteboard: [autoland-try:605854:try: -b do -p win32 -u all -t none
Comment on attachment 605854 [details] [diff] [review]
Adjust several test markings

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

Run 'er through try and we're good
Attachment #605854 - Flags: review?(joe) → review+
Whiteboard: [autoland-try:605854:try: -b do -p win32 -u all -t none → [autoland-try:605854:-b do -p win32 -u all -t none]
Whiteboard: [autoland-try:605854:-b do -p win32 -u all -t none] → [autoland-in-queue]
Autoland Patchset:
	Patches: 605854
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/pushloghtml?changeset=da1766ae1903
Try run started, revision da1766ae1903. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=da1766ae1903
Try run for da1766ae1903 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=da1766ae1903
Results (out of 49 total builds):
    exception: 1
    success: 37
    warnings: 11
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-da1766ae1903
Whiteboard: [autoland-in-queue]
I think we're close. reftests went green.

I am doing a dry run of all suites again.
No issues. We're ready.
Thanks Bas!
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
I did one last run and I discovered that one of the win7 slaves that was taking jobs was not really using a higher screen resolution.

talos-r3-w7-053 has a higher screen resolution and it does indeed fail on one more test:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332253145.1332255635.26560.gz&fulltext=1

REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==)

Sorry for giving high hopes :(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hi Bas,
These are the remaining issues:

* Rev3 WINNT 6.1 mozilla-central opt test reftest on 2012/03/21 07:36:53 

'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' '--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1332151882/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' 'reftest/tests/layout/reftests/reftest.list'

REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 817,1038; test browser size = 800,1000

http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332340613.1332343030.9668.gz&fulltext=1

REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==)

* Rev3 WINNT 6.1 mozilla-central opt test reftest-no-accel on 2012/03/20 17:17:32 
'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' '--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1332151882/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' '--setpref=gfx.direct2d.disabled=true' '--setpref=layers.acceleration.disabled=true' 'reftest/tests/layout/reftests/reftest.list'

REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 817,1038; test browser size = 800,1000

http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332289052.1332291471.20444.gz&fulltext=1

REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/abs-pos/auto-offset-inline-block-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2a.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2b.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2c.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2a.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2b.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613157-2.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/632423-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | view-source:file:///c:/talos-slave/test/build/reftest/tests/parser/htmlparser/tests/reftest/bug482921-1.html | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01a.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01b.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01c.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01d.svg | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==)
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #57)
> Hi Bas,
> These are the remaining issues:
> 
> * Rev3 WINNT 6.1 mozilla-central opt test reftest on 2012/03/21 07:36:53 
> 
> 'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe'
> '--utility-path=bin' '--extra-profile-file=bin/plugins'
> '--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-
> builds/mozilla-central-win32/1332151882/firefox-14.0a1.en-US.win32.
> crashreporter-symbols.zip' 'reftest/tests/layout/reftests/reftest.list'
> 
> REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET |
> DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 817,1038;
> test browser size = 800,1000
> 
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332340613.
> 1332343030.9668.gz&fulltext=1
> 
> REFTEST TEST-UNEXPECTED-FAIL |
> file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-
> overflow/xulscroll.html | image comparison (==)

I've figured out most of these except this one, do you have any idea here roc?

My patch needs to be applied at the same time as when Ru -actually- becomes unaccelerated though. As this is currently testing D2D with basiclayers(an unsupported configuration).
Ru is really Ru after bug 737049, no?
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #59)
> Ru is really Ru after bug 737049, no?

Right, so if Ru is green right now? How come you posted a bunch of failures up there? Or is it not green yet? I thought you said Ru was already being run.
What I know is that Ru in talos-r3-w7-53 fails:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332289052.1332291471.20444.gz&fulltext=1
and in production it succeeds:
https://tbpl.mozilla.org/php/getParsedLog.php?id=10285684&tree=Firefox&full=1

Both staging and production run with:
'--setpref=gfx.direct2d.disabled=true' '--setpref=layers.acceleration.disabled=true' 'reftest/tests/layout/reftests/reftest.list'

I will put talos-r3-w7-036 (the one that has the normal screen resolution) to take a Ru just to contrast.

If gfx wants we can ignore Ru for now and just hide it (even though I would prefer to both fixed at the same time) if there is just no time for this.

We can loan you the machine if you would like to.

Do you mind pushing to try the change you mentioned in comment 58? Please? That way I can test reftest-accelerated and hopefully move us one step forward.
I have verified that talos-r3-w7-036 goes green for Ru (this machine is using standard resolution rather than newer one).
I don't understand, something has to be wrong, if both are properly having acceleration disabled how can there be a difference.
Bas, I'm working with dividehex to add a dongle to 036 so at least we have 2 machines to get results from.

Would you be able to peak for a couple of hours in those 2 slaves? (pending the second one is ready)
So, the key question here is what is different about the other machine after adding a dongle? Can we confirm that they are indeed both -not- using acceleration in any way? I'd be willing to look at any logs, but this is a lot easier for someone to look at that has direct access to both machines.

For what it's worth, I think these are framework issue where somehow we're incorrectly detecting something or incorrectly disabling HWA, as both those builds should get !layersGPUAccelerated and it should fail or succeed on either of them. (whereas for example reftests/bidi/reftest.list believes it should fail if !layersGPUAccelerated).

All the dongle should do is make it possible to use Widget layers instead of BasicLayers for reftests. Before the dongle it would be possible for layerGPUAccelerated to be true, but the actual reftest still to be run in BasicLayers. I'm not sure how the dongle would influence the reftest result -if- HWA was indeed off on both machines.
(In reply to Bas Schouten (:bas) from comment #65)
> So, the key question here is what is different about the other machine after
> adding a dongle? Can we confirm that they are indeed both -not- using
> acceleration in any way? 
Sure. I will ensure they are the same tomorrow.

> I'd be willing to look at any logs, but this is a
> lot easier for someone to look at that has direct access to both machines.
>
I can give you access to both of them if you want to.
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #66)
> (In reply to Bas Schouten (:bas) from comment #65)
> > So, the key question here is what is different about the other machine after
> > adding a dongle? Can we confirm that they are indeed both -not- using
> > acceleration in any way? 
> Sure. I will ensure they are the same tomorrow.
> 
> > I'd be willing to look at any logs, but this is a
> > lot easier for someone to look at that has direct access to both machines.
> >
> I can give you access to both of them if you want to.

I don't actually know our reftest framework very well, particularly for build machines. I could launch firefox on them or run reftests from the command line and confirm hardware acceleration is disabled. But that wouldn't really tell us much as we know disabling hardware acceleration works. We need someone who can figure out what is -actually- being used when they run the reftests in their normal environment.

If all else fails I could add a patch with some printfs that somebody can apply and run and then we can actually see it properly from the logs.
I spoke with joe directly and I explained to him that:
* after dongles get attached "reftests" work and "reftest-non-accel" stop working

I am going to test all suites again, add slaves w7-036 into the mix (I have verified the correct screen resolution is in it after dividehex added the dongle last week) and make sure that "reftests" are accelerated and green.

If "reftest-no-accelerated" are still orange, we will disregard them and carry forward with deploying the dongles. We will fix Ru ("reftests-no-accel") in a follow up bug. joe agrees with this plan.

The reasoning is that we have to move forward and Ru is *only* enabled on mozilla-central and try.

I will post results tomorrow.
I lightning hit my head today and I hope this new idea would make this bug disappear immediately. We would call nircmd.exe setdisplay 1024 768 32 inside of a job instead of pre-buildbot-start.
This means we could deploy the dongles without a downtime and we could test the newer screen resolution on the try server first and then land a change on mozilla-inbound.
Let's fall in love with talos.json all over again if this works.

Otherwise we will have a painful downtime landing "disable tests during downtime and follow up later" on all branches (m-c, m-a, m-b, m-r, m-esr10 et all).
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #69)
> I lightning hit my head today and I hope this new idea would make this bug
> disappear immediately. We would call nircmd.exe setdisplay 1024 768 32
> inside of a job instead of pre-buildbot-start.
> This means we could deploy the dongles without a downtime and we could test
> the newer screen resolution on the try server first and then land a change
> on mozilla-inbound.
> Let's fall in love with talos.json all over again if this works.

Armen: did you get a chance to try this out?
Yes, I did.
I am getting mixed results from my quick looking:
http://dev-master01.build.scl1.mozilla.com:8041/builders/Rev3%20WINNT%206.1%20mozilla-central%20opt%20test%20reftest
I am triggering more jobs and I am trying to figure why I got only one green run.

I will post the failures tomorrow. I am thinking of asking for another machine or two to get a dongle to get more reliable results.
Assignee: bas.schouten → nobody
Component: Graphics → History: Global
QA Contact: thebes → history.global
Assignee: nobody → bas.schouten
Component: History: Global → Graphics
QA Contact: history.global → thebes
Bas, could you please review these results?

I know that it has once passed (slave036):
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1333665310.1333667535.3128.gz&fulltext=1
but I know that it has failed on the same test for both slaves:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1334011608.1334013880.2243.gz&fulltext=1#err0

I can tell that the difference is focus. Perhaps I VNCed to the machine prior to starting the job.

What do you think?
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #72)
> Bas, could you please review these results?
> 
> I know that it has once passed (slave036):
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1333665310.
> 1333667535.3128.gz&fulltext=1
> but I know that it has failed on the same test for both slaves:
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1334011608.
> 1334013880.2243.gz&fulltext=1#err0
> 
> I can tell that the difference is focus. Perhaps I VNCed to the machine
> prior to starting the job.
> 
> What do you think?

That's not a graphics issue, that's some side-effect of the dongle probably, causing a window to get focus somehow or something of the likes. Someone in content or editor or something like that probably has a better idea of what's going on there.
Hi bz/ehsan,
For context, we have been running Windows 7 machines without dongles which means that we run at a lower resolution and thus not running reftests with accelerated hardware.
We are now trying to attach the dongles without turning a bunch of tests permanently orange. We are trying to figure out all of these oranges on staging first.

In comment 72 I describe how two machines that have dongles attached fail on a specific test due to focus on a button of a form (only one of the many runs went green).

We need help figuring out why this is happening and hopefully fix the test or underlying problem.

This is quite an important work and any help in the right direction would be extremely helpful.
Is that a focus effect, or a hover effect?  If it's a hover effect, it could simply be a matter of mouse pointer position or some such... we've had issues like that with reftests involving form controls before.
I have added a step to move the cursor to the top right side of the screen.
Let's side what it yields.
Is there a way to change the mouse position through our test infrastructure?

I am trying to use "nircmd.exe setcursor 1010 10" but it only works when I open a command prompt on the VNC session (it doesn't work through ssh, buildbot or start up bat files).
If the issue really is hover state, we could also fix the test to not depend on hover state.
bz, if you could that for me it would be great. If you could push the change to the try server I could then try on staging.

My python script seems to have failed when running through ssh (from VNCing into it I assume it did not work through buildbot regardless of the return code being 0):

C:\talos-slave\test\build>cat setMousePosition.py
import win32api, win32con

def click(x,y):
    win32api.SetCursorPos((x,y))

click(1010,10)

### the following error is when I ssh into it
C:\talos-slave\test\build>C:\mozilla-build\python25\python.exe setMousePosition.py
Traceback (most recent call last):
  File "setMousePosition.py", line 6, in <module>
    click(1010,10)
  File "setMousePosition.py", line 4, in click
    win32api.SetCursorPos((x,y))
pywintypes.error: (1459, 'SetCursorPos', 'This operation requires an interactive window station.')
I am running setMousePosition.py [1] through buildbot and through startTalos.bat.
Their output seems to succeed [2] but when I connect through VNC I can still see the cursor in the middle of the screen rather than at the top right.
I am waiting on results and I really hope that it succeeds as I can't spend much more time on this during this week as I have a release and the SPDY work that is over-due.

[1]
import win32api
import win32gui

info = win32gui.GetCursorInfo()
print "Previous mouse position: (%s, %s)" % (info[2][0], info[2][1])
win32api.SetCursorPos((1010,10))
info = win32gui.GetCursorInfo()
print "Next mouse position: (%s, %s) "% (info[2][0], info[2][1])

[2]
'C:\\mozilla-build\\python25\\python.exe' 'setMousePosition.py'
 in dir c:\talos-slave\test\build (timeout 1200 secs)
 watching logfiles {}
 argv: ['C:\\mozilla-build\\python25\\python.exe', 'setMousePosition.py']
 environment:
  ALLUSERSPROFILE=C:\ProgramData
  APPDATA=C:\Users\cltbld\AppData\Roaming
  COMMONPROGRAMFILES=C:\Program Files\Common Files
  COMPUTERNAME=TALOS-R3-W7-053
  COMSPEC=C:\Windows\system32\cmd.exe
  FP_NO_HOST_CHECK=NO
  HOMEDRIVE=C:
  HOMEPATH=\Users\cltbld
  LOCALAPPDATA=C:\Users\cltbld\AppData\Local
  LOGONSERVER=\\TALOS-R3-W7-053
  MOZ_CRASHREPORTER_NO_REPORT=1
  MOZ_NO_REMOTE=1
  NO_EM_RESTART=1
  NUMBER_OF_PROCESSORS=2
  OS=Windows_NT
  PATH=C:\mozilla-build;C:\mozilla-build\msys\bin;C:\mozilla-build\msys\local\bin;C:\mozilla-build\buildbotve\scripts;C:\mozilla-build\Python25;C:\mozilla-build\Python25\Scripts;C:\mozilla-build\hg;C:\mozilla-build\7zip;C:\mozilla-build\upx203w;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32;C:\WINDOWS;
  PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
  PROCESSOR_ARCHITECTURE=x86
  PROCESSOR_IDENTIFIER=x86 Family 6 Model 23 Stepping 10, GenuineIntel
  PROCESSOR_LEVEL=6
  PROCESSOR_REVISION=170a
  PROGRAMDATA=C:\ProgramData
  PROGRAMFILES=C:\Program Files
  PROMPT=$P$G
  PSMODULEPATH=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
  PUBLIC=C:\Users\Public
  PWD=c:\talos-slave\test\build
  SYSTEMDRIVE=C:
  SYSTEMROOT=C:\Windows
  TEMP=C:\Users\cltbld\AppData\Local\Temp
  TMP=C:\Users\cltbld\AppData\Local\Temp
  USERDOMAIN=TALOS-R3-W7-053
  USERNAME=cltbld
  USERPROFILE=C:\Users\cltbld
  WINDIR=C:\Windows
  XPCOM_DEBUG_BREAK=warn
 using PTY: False
Previous mouse position: (641, 513)
Next mouse position: (1010, 10) 
program finished with exit code 0
elapsedTime=0.201000
> If you could push the change to the try server I could then try on staging.

https://tbpl.mozilla.org/?tree=Try&rev=32db3b73f980
Thanks bz.
I spoke with joduinn and I need to focus on SPDY work (which is over-due) before I head out for the MozCamp next Wednesday.
As soon as that is done I will need 2-4 days heads down on this to make sure that I have the full picture of what exactly needs fixing.

My plan is:
1) modify startTalos.bat to run current screen resolution
** make sure that we don't get any oranges on any branch
2) verify that we can attach the dongles without producing any new oranges
** ask IT to deploy the dongles
3) modify factory.py to allow setting the screen resolution from the code side
** this would allow pushing to the try server a higher screen resolution
** this would allow pushing to m-c and populate to other branches

As soon as #1 is done I am inclined to say that #2 and #3 will be very easy.
To accomplish #1, I have to verify the mouse pointer issue with the try server push or perhaps modify the test harness.
Assignee: bas.schouten → nobody
Priority: -- → P2
Target Milestone: mozilla12 → ---
Assignee: nobody → armenzg
Sorry for my delay here, but it seems like you guys have been making progress here.  I didn't fully read the comments here (it's 12AM now!) but if my assistance is still required, please let me know what I can help with (or ping me on IRC to have a chat).  Thanks!
Any news here guys?
This is incredibly critical. With no testing of D2D on Tinderbox, we basically have no testing of the graphics code that some large percentage of our users use.

This is a lot more important than SPDY.
My priority is now on Windows 8.
SPDY got done a while ago.
I know this is important.
Priority: P2 → P3
Component: Graphics → Release Engineering: Platform Support
Product: Core → mozilla.org
QA Contact: thebes → coop
Version: unspecified → other
If you're setting up Windows 8 test machines that will test with accelerated rendering, that will take some of the urgency out of this bug.

If you're not doing that, then I'm still very worried.
Just as a note:

As we're switching on Azure-Thebes. This bug means we will now go to not just having an untested Layers backend. But a completely untested rendering backend, since Azure is bypassed when using BasicLayers. In other words we'll know if Azure is triggering assertions or crashing (since the drawing to the window still happens with Azure). But we will -not- know if Azure is drawing incorrectly.
Priority: P3 → P2
Attached file [wip] mouse_and_screen_resolution.py (obsolete) —
I am running this.
I am now going to try proper formal jobs.

################################################################################
  self.addStep(ShellCommand(
      name='download script',
      command=['wget', '--no-check-certificate', '-Omouse_and_screen_resolution.py','http://people.mozilla.com/~armenzg/incoming/mouse_and_screen_resolution.py'],
      flunkOnFailure=True,
      haltOnFailure=True,
      ))
  self.addStep(ShellCommand(
      name='run script',
      command=['C:\\mozilla-build\\python25\\python.exe', 'mouse_and_screen_resolution.py'],
      flunkOnFailure=True,
      haltOnFailure=True,
      ))
################################################################################
'C:\\mozilla-build\\python25\\python.exe' 'mouse_and_screen_resolution.py'
...
Screen resolution (current): (1280, 1024)
Screen resolution (new): (1024, 768)
Mouse position (current): (512, 384)
Mouse position (new): (1010, 10)
I feel that a code similar to this should live in layout/tools/reftest/runreftest.py.

roc, joe, jmaher: what do you think?

This code right now is a no-op that would allow IT to attach the dongles and for developers to push to try newer screen resolutions.

Armens-MacBook-Air:mozilla-inbound armenzg$ cat testing/configuration.json 
{
    "screen_resolution": {
        "x": 1024,
        "y": 768
    },
    "mouse_position": {
        "x": 1010,
        "y": 10
    }
}
Attachment #629870 - Attachment is obsolete: true
Attachment #630315 - Flags: feedback?(roc)
Attachment #630315 - Flags: feedback?(jmaher)
Should we put this in automation.py.in so any test can use it?

configuration.json could be a little more descriptive. Say machine-configuration.json?

So the idea is that we check this in, then we can push to try with changes to machine-configuration.json and get the desired screen size/mouse position etc? Then when try's green, we push the configuration change to mozilla-central? That sounds good. Especially if we can extend it to other platforms later.
Comment on attachment 630315 [details] [diff] [review]
[tools] mouse_and_screen_resolution.py

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

a few comments, I really think we need to put error checking around the setresolution stuff as indicated below

::: scripts/support/mouse_and_screen_resolution.py
@@ +17,5 @@
> +import os, sys
> +import urllib2
> +import win32api
> +import win32con
> +import pywintypes

are these python modules available inside our python evironment?  I believe we have python 2.5 that we use, but we would have to install these separate.  If we do have these installed we could probably switch to python 2.5 for talos on windows :)  Likewise will this run on all windows platforms (xp, win7, w764)?  I see the comment below that this is designed for w7 32 bit only, my concern is the imports here will fail on xp if you don't have the python modules installed.

@@ +60,5 @@
> +    if current_screen_resolution == new_screen_resolution:
> +        print "No need to change the screen resolution."
> +    else:
> +        print "Changing the screen resolution..."
> +        changeScreenResolution(new_screen_resolution)

do we have to consider it might take a second or two here for this to change?

@@ +100,5 @@
> +        display_modes[key] = devmode
> +        n += 1
> +
> +    mode_required = (32, new["x"], new["y"], 60)
> +    devmode = display_modes[mode_required]

what if the 32,x,y,60 is not an option?  This with throw a python error.
Attachment #630315 - Flags: feedback?(jmaher) → feedback-
jmaher I will tackle your comments tomorrow or Friday.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #92)
> Should we put this in automation.py.in so any test can use it?
> 
I will leave this for a follow up bug in case anyone wants to extend this beyond Win7 and reftests. I would remove my code at that point.

> configuration.json could be a little more descriptive. Say
> machine-configuration.json?
> 
Sounds good.

> So the idea is that we check this in, then we can push to try with changes
> to machine-configuration.json and get the desired screen size/mouse position
> etc? Then when try's green, we push the configuration change to
> mozilla-central? That sounds good. Especially if we can extend it to other
> platforms later.

This is correct. It will be possible to extend to other platforms. We will see where we need it.
> > +    mode_required = (32, new["x"], new["y"], 60)
> > +    devmode = display_modes[mode_required]
> 
> what if the 32,x,y,60 is not an option?  This with throw a python error.

I have tested this and I would get a "KeyError: (a, b, c, d)" traceback and an error exit code.

Should I bother adding a try/except block if it would make buildbot stop the job without changing anything?
is it cleaner to have code than handles known possible exceptions, but either way we need to make buildbot continue or stop, so as long as the log files make sense to understand what is happening I am fine with either way.
Attachment #630315 - Attachment is obsolete: true
Attachment #630315 - Flags: feedback?(roc)
Attachment #630938 - Flags: review?(jmaher)
Attachment #630938 - Flags: review?(coop)
Attached patch machine-configuration.json (obsolete) — Splinter Review
FTR I have also tested the script on win7 64-bit and WinXP.
Attachment #630939 - Flags: review?(jmaher)
Comment on attachment 630938 [details] [diff] [review]
[tools] mouse_and_screen_resolution.py

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

just a few minor things.

::: scripts/support/mouse_and_screen_resolution.py
@@ +4,5 @@
> +# file, You can obtain one at http://mozilla.org/MPL/2.0/.
> +
> +#
> +# Script name:   mouse_and_screen_resolution.py
> +# Purpose:       Sets mouse position and screen resolution for Windows slaves

windows 7 32 bit slaves

@@ +28,5 @@
> +
> +def main():
> +    '''
> +    We load the configuration file from:
> +    http://hg.mozilla.org/mozilla-central/raw-file/default/build/configuration.json

did we still want to call this configuration.json?  I agree with roc's comment about how ambiguous that sounds.

@@ +79,5 @@
> +    print "Mouse position (new): (%(x)s, %(y)s)" % (current_mouse_position)
> +
> +    if current_screen_resolution != new_screen_resolution or current_mouse_position != new_mouse_position: 
> +        print "INFRA-ERROR: The new screen resolution or mouse positions are not what we expected"
> +        return 1

can we explicitly return 0 on success?

@@ +106,5 @@
> +          devmode.DisplayFrequency
> +        )
> +        display_modes[key] = devmode
> +        n += 1
> +

mixing 2 and 4 space indentation here, please correct to 4 space.
Attachment #630938 - Flags: review?(jmaher) → review+
Comment on attachment 630939 [details] [diff] [review]
machine-configuration.json

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

can we comment that this is for windows 7 32 bit?  Or is this going to be used for other purposes?
Attachment #630939 - Flags: review?(jmaher) → review+
I addressed the comments by jmaher.
Attachment #630938 - Attachment is obsolete: true
Attachment #630938 - Flags: review?(coop)
Attachment #630975 - Flags: review?(coop)
Added platform specific entry.
Attachment #630939 - Attachment is obsolete: true
Attachment #630977 - Flags: review?(jmaher)
Comment on attachment 630977 [details] [diff] [review]
[inbound] machine-configuration.json

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

cool, please make sure the file that reads this is updated as well.
Attachment #630977 - Flags: review?(jmaher) → review+
Comment on attachment 630975 [details] [diff] [review]
[tools] mouse_and_screen_resolution.py

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

Script looks good. I would echo jmaher's comment but go further: if this script is really only ever going to be used on Win7, we should add 'win7' to the name of the script as a further clue that it shouldn't be expected to work elsewhere.
Attachment #630975 - Flags: review?(coop) → review+
Once we have this working we should expect some accelerated reftests to fail again since we switched on Azure content. I wasn't able to mark them fuzzy because the exact behavior is hardware dependent. I'll need to get a D2D enabled run from the test machines so I can adjust the fuzziness of the tests.
Attachment #630975 - Flags: checked-in+
Attachment #630977 - Flags: checked-in+
The script even if run on Windows XP or Windows 7 64-bit it would simply skip it.

I have to modify the script for the case where hg is down momentarily rather than falling on the default values I added (which are good for trees without the json file). I know that hg blips occur all the time since I had to add in-step-retry logic for the talos_from_code.py code.
I changed C:\Windows\System32\drivers\etc\hosts to point hg.m.o to localhost.
Attachment #631410 - Flags: review?(jmaher)
Comment on attachment 631410 [details] [diff] [review]
[tools] handle the situation when hg is down

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

looking good.
Attachment #631410 - Flags: review?(jmaher) → review+
We need a larger screen resolution for accelerated reftests.

We need to move the mouse away because it causes so many oranges for various test suites.

Remaining plan of actions:
* Monday - deploy this buildbotcustom patch
* Tuesday - dividehex deploys 5 dongles to production machines
** This should be a no-op since they should run at 1024x768 instead of 1200x1024
* Tuesday - /me watches for any fallouts if any on those 5 machines
* Wednesday - go/no-go for IT to deploy remaining dongles whenever suits them best
** we can ask buildduty to disable slaves ahead of time for IT to deploy dongles when not running jobs
** OR ask for a small downtime (we can determine which one we want/need)
Attachment #631120 - Attachment is obsolete: true
Attachment #631495 - Flags: review?(coop)
Comment on attachment 631495 [details] [diff] [review]
[buildbotcustom] run new screen resolution and mouse position for all unit tests jobs for Windows 7 32-bit slaves

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

::: process/factory.py
@@ +6816,5 @@
>                  name='disable_screensaver',
>                  command=['xset', 's', 'reset'],
>                  env=self.env,
>              ))
> +        if self.platform.startswith('win32'):

Should this be win7 instead of win32?
Attachment #631495 - Flags: review?(coop) → review+
(In reply to Chris Cooper [:coop] from comment #111)
> > +        if self.platform.startswith('win32'):
> 
> Should this be win7 instead of win32?

Right now, UnitttestPackagedFactory don't have that fine graining. The script mouse_and_screen_resolution.py skips running on XP and Win7 64-bit.
Comment on attachment 631495 [details] [diff] [review]
[buildbotcustom] run new screen resolution and mouse position for all unit tests jobs for Windows 7 32-bit slaves

http://hg.mozilla.org/build/buildbotcustom/rev/2945a9b02531

As I said, this should be a no-op change even after the dongles get attached (since I enforce 1024x768 which is what we run right now).

I will deploy this on Monday and continue the plan as mentioned on the previous comment.
Attachment #631495 - Flags: checked-in+
Comment on attachment 631410 [details] [diff] [review]
[tools] handle the situation when hg is down

This patch landed last week:
http://hg.mozilla.org/build/tools/rev/6df476d6cf98
Attachment #631410 - Flags: checked-in+
This code has been merged to the production branch and masters have been reconfigured around 7:40 AM PDT.

This means that we have landed code in preparation for adding 5 dongles tomorrow.

This is a no-op change even after we attach the dongles.
This seems to have stick properly (at least for try - waiting on more results):
https://tbpl.mozilla.org/php/getParsedLog.php?id=12553362&tree=Try&full=1
This branch does not seem to have the configuration file HTTP Error 404: Not Found
Let's fail over to 1024x768.
Screen resolution (current): (1024, 768)
No need to change the screen resolution.
Mouse position (current): (513, 385)
Mouse position (new): (1010, 10)
program finished with exit code 0
elapsedTime=1.301000

For Windows XP:
INFO: This script was written to be used with Windows 7 32-bit machines.
No longer blocks: 710233
Depends on: 710233
Blocks: 702504
The dependency and descriptions of these bugs have been somehow mixed (mea culpa).

We ended up doing investigation and fix the releng side on this bug.

I propose opening a new bug for the gfx to work on increasing a larger screen resolution.
Thoughts?
Summary: Fix perma-oranges for accelerated reftests → Allow devs to change screen resolution in-tree so they can try larger screen resolutions
Sounds good to me.
I tested that we can change the screen resolution and mouse position by landing code changes:
https://hg.mozilla.org/try/rev/84d83c001cad

Screen resolution (current): (1024, 768)
Changing the screen resolution...
Screen resolution (new): (1280, 1024)
Mouse position (current): (640, 512)
Mouse position (new): (1270, 10)
program finished with exit code 0

This also causes oranges to show up:
https://tbpl.mozilla.org/php/getParsedLog.php?id=13080585&tree=Try&full=1
https://tbpl.mozilla.org/php/getParsedLog.php?id=13100834&tree=Try&full=1

I will push bug 702504 to the gfx team to finish up any remaining work.

Yay!
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Blocks: 774611
Blocks: 784623
Product: mozilla.org → Release Engineering
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.