LW-theme background images aren't shown
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: Paenglab, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
LW-theme background images do not show any more.
Back-out of bug 1665064 fixes it for me.
Emilio, do you know why this happens? I CCed Magnus if you have questions about deeper functions.
Assignee | ||
Comment 1•4 years ago
|
||
What are LW-theme background images? Can you attach an screenshot?
(No idea why off-hand, we should only skip painting backgrounds during print).
Reporter | ||
Comment 2•4 years ago
|
||
This screenshot shows the LW-theme "Dark Fox" applied. In front the smaller window how it should look and on background how it looks now.
Maybe this happens on TB because TB doesn't use electrolysis.
Reporter | ||
Comment 3•4 years ago
|
||
I'm a complete noob in Cpp so I don't really know what I'm doing. With a back-out of only the changes in nsDisplayList.cpp the LW-theme image is shown again. A back-out of only the changes in nsCanvasFrame.cpp shows still the issue.
Emilio, not sure if that helps you.
Assignee | ||
Comment 4•4 years ago
|
||
Sorry for the lag in looking into this. So if I back out my patch, on a debug build I get:
Assertion failure: mFrame->IsCanvasFrame() || mFrame->IsFrameOfType(nsIFrame::eTablePart), at /home/emilio/src/moz/gecko-5/layout/painting/nsDisplayList.cpp:3355
So something is a bit off...
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Reporter | ||
Comment 6•4 years ago
|
||
I tried your patch on Linux and Windows on TB.
- On both platforms the Add-on manager fills only the top fifth of the window.
- On both platforms the DevTools Toolbox (Browser Toolbox on FX) fills also only the top fifth of the window.
- On Linux the theme background image is displayed but with the dark or light theme the titlebar and tabbar are transparent.
- On Windows first the theme background looked good but after a restart of TB the whole window is transparent. Also in safe mode no change. The safe mode dialog is also transparent but the text is still visible.
Assignee | ||
Comment 7•4 years ago
|
||
Alright, I'll look into that, there's also a bit of orange in my try push.
Assignee | ||
Comment 8•4 years ago
|
||
The updated patch should be much closer if you want to give it a run. I still need to fix one or two existing xul tests, but won't get to that today.
Reporter | ||
Comment 9•4 years ago
|
||
On Linux all is looking good but Windows still shows a completely transparent window. Absolute nothing is visible. When I start in safe mode, the safe mode dialog is shown with the content but no window decoration (no titlebar, no window border).
Assignee | ||
Comment 10•4 years ago
|
||
Can you check on a debug build to see if there's any assertion going on?
Reporter | ||
Comment 11•4 years ago
|
||
I attached the log when starting with mach run. Before I built without the patch and correlated both outputs. No additional assertions are in the log.
But with your patch I see this line:
[GFX2-]: ASurface Init failed with Cairo status 1 on 00007FFDB7D0A660
and this:
WARNING: GetImageSurface on an invalid (null) surface; who's calling this without checking for surface errors?: file z:/Mozilla/comm-central/gfx/thebes/gfxWindowsSurface.cpp, line 149
Reporter | ||
Comment 14•4 years ago
|
||
Emilio, can my log and comment 11 help you find the issue?
Assignee | ||
Comment 15•4 years ago
|
||
(In reply to Richard Marti (:Paenglab) from comment #14)
Emilio, can my log and comment 11 help you find the issue?
Yes, I know what the issue is already, it was just harder to fix than it seemed, I just got all the dependencies sorted out and can try to land this again.
Assignee | ||
Comment 16•4 years ago
|
||
My patch somehow causes WR to crash and fall back to d2d on Windows, see
bug 1671591.
While I figure that out let's fix TB by restoring the previous behavior
for XUL.
Rename the Root frame type because it's super-confusing that IsRootFrame
is not equivalent to !GetParent().
Assignee | ||
Comment 17•4 years ago
|
||
Can you confirm comment 16 fixes it for you too? The proper fix will take a bit more because of bug 1671591 and me being sick this week :(
Reporter | ||
Comment 18•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)
Can you confirm comment 16 fixes it for you too? The proper fix will take a bit more because of bug 1671591 and me being sick this week :(
Yes, this fixes the background image issue. Many thanks.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
bugherder |
Assignee | ||
Comment 23•4 years ago
|
||
It seems like nowadays the WR failure is much noisier, and I should be able to debug it better... https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=E-0RYZy_SR6LwPIc6gjgGA.0&revision=92edd731e64cc448719e8dac6ae573efda121463
Comment 24•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #23)
It seems like nowadays the WR failure is much noisier, and I should be able to debug it better... https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=E-0RYZy_SR6LwPIc6gjgGA.0&revision=92edd731e64cc448719e8dac6ae573efda121463
Bug 1671591 is P3, so perhaps won't get attention soon.
Assignee | ||
Comment 25•3 years ago
|
||
I checked and bug 1671591 doesn't seem to keep happening, so I'll rebase and reland.
Comment 26•3 years ago
•
|
||
Backed out changeset e41bfdf79fb8 (Bug 1665476) for causing windows mochitest failures in test_windowminmaxsize.xhtml
Backout link: https://hg.mozilla.org/integration/autoland/rev/54f245b73e54063142fb0d7e1a493401f6389cfd
Push with failures, failure log.
(Update): Looks to have also caused bc failures.
Assignee | ||
Updated•3 years ago
|
Updated•2 years ago
|
Comment 27•2 years ago
|
||
Comment 28•2 years ago
|
||
Backed out for causing mochitest mass failures.
Backout link: https://hg.mozilla.org/integration/autoland/rev/8280e8cef3ae5f2028521ace665f63c8879d1084
Failure logs:
https://treeherder.mozilla.org/logviewer?job_id=391550429&repo=autoland&lineNumber=8719
https://treeherder.mozilla.org/logviewer?job_id=391548502&repo=autoland&lineNumber=7757
Comment 29•2 years ago
|
||
Assignee | ||
Updated•2 years ago
|
Comment 30•2 years ago
|
||
bugherder |
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•