Closed
Bug 862655
Opened 11 years ago
Closed 9 years ago
VS2012 and Windows 8 SDK fails toolkit/content/tests/chrome/test_panel.xul with "noautohide panel with titlebar top less"
Categories
(Core :: Widget: Win32, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: bkelly, Assigned: emk)
References
Details
Attachments
(1 file)
1.32 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
I am currently running into the following error on a windows 8 vmware fusion instance: 0:14.42 39 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_panel.xul | noautohide panel with titlebar top less The test in question looks like this: var panelrect = panel.getBoundingClientRect(); ok(panelrect.top <= 210 - mozInnerScreenY + 30, testname + "top less"); Adding some debug shows that: panelrect.top === 10 210 - mozInnerScreenY + 30 === 9 My working theory is this shows up for me, but not the try server because I build with the win8 SDK included in visual studio express 2012. Apparently the try servers use vs2010 and win7 SDK.
Comment 1•11 years ago
|
||
CC'ing Tim who did some work for the titlebar being too big when using the win8 SDK.
Comment 2•11 years ago
|
||
I don't have any immediate ideas after looking over this test. I believe that we were, at one point, able to build and run all tests using VS2012 and the Win8 SDK, so a good first step might be to find a regression range for this issue.
Reporter | ||
Comment 3•11 years ago
|
||
I can confirm that installing VS2010 and Win7 SDK resolves this problem. Unfortunately I'm working with a fairly small/slow VM, so I can't easily support both environments and switching between revisions. In a couple weeks I expect to have a better setup, so I will revisit then.
Reporter | ||
Updated•11 years ago
|
Summary: toolkit/content/tests/chrome/test_panel.xul fails on win8 with "noautohide panel with titlebar top less" → VS2012 and Windows 8 SDK fails toolkit/content/tests/chrome/test_panel.xul with "noautohide panel with titlebar top less"
Assignee | ||
Comment 4•10 years ago
|
||
See bug 1094013 comment #9 about a minimized testcase.
Assignee | ||
Comment 5•10 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from bug 1094013 comment #9) > |panelrect.top <= 210 - mozInnerScreenY + 30| still holds for me, but the > popup is actually shifted. So this is a real bug. Actually this was by design! If DWM is enabled, the border width of non-resizable windows is extended. To keep compatibility with older apps, DWM will tell a lie to apps whose subsystem version is lower than 6.0 [1]. So the test running on 32-bit Firefox did not notice the metric change. We should increase the number a bit to accommodate the taller title bar. [1] https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/6c1c67a9-5548-4e9b-989f-c7dbac0b1375/getwindowrect-on-nonresizable-windows-under-aero-glass?forum=windowsuidevelopment
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8519398 -
Flags: review?(enndeakin)
Assignee | ||
Comment 7•10 years ago
|
||
Try run with patches from bug 1094013 and this bug: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=d5214200d0dd
Assignee | ||
Comment 8•9 years ago
|
||
Comment on attachment 8519398 [details] [diff] [review] Increase a margin number a bit to accommodate the taller title bar on Windows with DWM enabled Enn has no activity for the last two weeks. (On vacation?) https://bugzilla.mozilla.org/page.cgi?id=user_activity.html&action=run&from=-14d&who=enndeakin%40gmail.com Roc, could you take a look?
Attachment #8519398 -
Flags: review?(roc)
Updated•9 years ago
|
Attachment #8519398 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 9•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e20b1911e1e0
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Flags: in-testsuite-
https://hg.mozilla.org/mozilla-central/rev/e20b1911e1e0
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Attachment #8519398 -
Flags: review?(roc)
You need to log in
before you can comment on or make changes to this bug.
Description
•