502424 - Window transparent does not work

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[AKIHIRO Misaki (a.k.a Kuden)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090704 Minefield/3.6a1pre {Build ID: 20090704190158}

Steps to Reproduce:
1. Tools -> Options... -> Advanced -> General -> Browsing
2. checked "Use autoscrolling"
3. Web page to which the scrollbar is displayed is opened
4. middle click

or, click the List all Tabs button.

Actual Results: 
Neither autoscroll icon nor Ctrl+tab panel transparent.

Expected Results:
work Window transparent

Comment 1

[AKIHIRO Misaki (a.k.a Kuden)]

regression by Bug 488242?

Comment 2

[Timothy Nikkel (:tnikkel)]

(In reply to comment #1)
> regression by Bug 488242?

Yes. I know the problem. Patch coming soon.

Comment 3

[Kirk M]

Would this be the same bug that's affecting both 3.5 and 3.5.1(pre) in that the autoscroll icon is not showing the 4-way arrows but rather a small square blank box?

Comment 4

[Martijn Wargers (dead)]

Kirk, no, this bug was a regression from bug 488242, which only landed on trunk, so this is a trunk specific problem, not on 3.5.
If you have a problem in Firefox3.5 (which might look like this problem), then please file a new bug for that (if there isn't one already).

Comment 5

[Bill Gianopoulos [:WG9s]]

(In reply to comment #3)
> Would this be the same bug that's affecting both 3.5 and 3.5.1(pre) in that the
> autoscroll icon is not showing the 4-way arrows but rather a small square blank
> box?
If you see this issue using 3.5, I would suspect you are NOT using the default theme, and the theme you are using was not updated for 3.5.

Comment 6

[Kirk M]

Bill - My bad for not posting the particulars. This problem was seen on both Firefox 3.5 and Shiretoko 3.5.1pre using default theme in Safe Mode and using a fresh profile. OS is WinXP SP3 (newly reloaded 6 days ago).

Comment 8

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

Same applies to the edit bookmark panel (Cmd+D). Would be nice to have an automated test for that. It has been regressed at least twice now.

Comment 9

[Timothy Nikkel (:tnikkel)]

(In reply to comment #8)
> Same applies to the edit bookmark panel (Cmd+D). Would be nice to have an
> automated test for that. It has been regressed at least twice now.

Agreed. Bug 478784 is one of those regressions, and comment 15 of that bug explains why a test wasn't added then. I'm hoping that some of the changes made with bug 488242 to unify to a small extent PresShell::RenderDocument and PresShell::Paint will allow me to create a test for this.

If its not too hard for you to find the bug numbers for the other regressions of this I would be interested in looking at those.

Comment 10

[Timothy Nikkel (:tnikkel)]

Attachment: patch

The problem here is that PresShell::Paint is called on a view whose frame is a MenuPopup, and the subtree rooted at the MenuPopup frame does not contain a canvas frame (in terms of nsCSSRendering::IsCanvasFrame). But we attempt to draw the background color of the root element style frame. The parent chain for the MenuPopup frame looks like this: Viewport > RootBox > DocElementBox > PopupSet > Popup-list for PopupSet > MenuPopup.

Now bug 478784 was the same problem, it was solved by checking if the nearest widget was not opaque and not drawing the cached canvas color in that case. This would miss cases (do any such cases exist?) where we call PresShell::Paint on a subtree without a canvas frame that have an opaque widget.

As I said above, I hope that I can create an automated test for this. But for now, just the patch.

Comment 11

[Timothy Nikkel (:tnikkel)]

Attachment: patch v2

All that code was just a long winded way of saying !nsCSSRendering::IsCanvasFrame(aFrame). So use that instead.

Comment 12

[Timothy Nikkel (:tnikkel)]

I'm afraid I can't think of a way to test this. Although RenderDocument (the guts of DrawWindow) now uses the cached background color, there is no way for that color to be invalid like in this bug because RenderDocument is called on a PresShell and does not have a frame parameter. It just uses the root element frame to draw. So it doesn't draw some other frame lower in the frame tree where drawing the root background color would mess things up.

Comment 15

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/93bcc8dff9a1

Comment 16

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

(In reply to comment #12)
> I'm afraid I can't think of a way to test this. Although RenderDocument (the

Jonathan, would you have an idea for a reftest?

Comment 17

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

Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090709 Minefield/3.6a1pre ID:20090709035810.

The star panel (editBookmarksPanel) look fine now again. Thanks! Can we probably use a modified version of this panel for a reftest?

Comment 18

[Timothy Nikkel (:tnikkel)]

(In reply to comment #17)
> The star panel (editBookmarksPanel) look fine now again. Thanks! Can we
> probably use a modified version of this panel for a reftest?

The problem is that PresShell::RenderDocument (which the reftest framework uses to get a screenshot of what is painted) only paints starting from a root frame. panel's are never root frames. This bug was caused because we paint (via PresShell::Paint, the function that paints to the screen) a non-root frame using the cached background color of the root frame.

If anyone has any ideas for how to test this let me know.