Window transparent does not work

VERIFIED FIXED in mozilla1.9.2a1

Status

()

defect
--
major
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: spitfire.kuden, Assigned: tnikkel)

Tracking

({regression})

Trunk
mozilla1.9.2a1
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

10 years ago
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
Reporter

Comment 1

10 years ago
regression by Bug 488242?
Blocks: 488242
Severity: normal → major
Keywords: regression
Assignee

Comment 2

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

Yes. I know the problem. Patch coming soon.
Assignee: nobody → tnikkel
Version: unspecified → Trunk

Comment 3

10 years ago
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?
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).
(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

10 years ago
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).
Duplicate of this bug: 502626
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.
Flags: in-testsuite?
Assignee

Comment 9

10 years ago
(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.
Assignee

Comment 10

10 years ago
Posted patch patch (obsolete) — Splinter Review
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.
Attachment #387158 - Flags: superreview?(roc)
Attachment #387158 - Flags: review?(roc)
Blocks: 463519
Attachment #387158 - Flags: superreview?(roc)
Attachment #387158 - Flags: superreview+
Attachment #387158 - Flags: review?(roc)
Attachment #387158 - Flags: review+
Assignee

Comment 11

10 years ago
Posted patch patch v2Splinter Review
All that code was just a long winded way of saying !nsCSSRendering::IsCanvasFrame(aFrame). So use that instead.
Attachment #387158 - Attachment is obsolete: true
Attachment #387243 - Flags: superreview?(roc)
Attachment #387243 - Flags: review?(roc)
Attachment #387243 - Flags: superreview?(roc)
Attachment #387243 - Flags: superreview+
Attachment #387243 - Flags: review?(roc)
Attachment #387243 - Flags: review+
Assignee

Updated

10 years ago
Keywords: checkin-needed
Whiteboard: [needs landing]
Assignee

Comment 12

10 years ago
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.
Duplicate of this bug: 503163
http://hg.mozilla.org/mozilla-central/rev/93bcc8dff9a1
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla1.9.2a1
(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?
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?
Status: RESOLVED → VERIFIED
Assignee

Comment 18

10 years ago
(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.
Assignee

Updated

10 years ago
Depends on: 525751
You need to log in before you can comment on or make changes to this bug.