[Windows-only] Content rendering anomalies after the landing of bug 130078

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: jimm, Assigned: tnikkel)

Tracking

Trunk
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta5+)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
Created attachment 470216 [details]
screen shots

Open pretty much any site, flip between full screen and normal view a few times. Content gets shifted, moved around or clipped. Win7, gdi rendering.
(Reporter)

Updated

8 years ago
blocking2.0: --- → ?
(Reporter)

Comment 1

8 years ago
http://popuptest4ff.de.tl 


A test case page I can easily reproduce this on. But I've seen it on bugzilla pages as well.
(Reporter)

Updated

8 years ago
Duplicate of this bug: 591784
(Reporter)

Comment 3

8 years ago
The same can be reproduce using the sidebar, see bug 591784.
Blocks: 130078
Component: Layout → Layout: View Rendering
QA Contact: layout → layout.view-rendering
Summary: Content rendering anomalies when flipping between fullscreen and normal view → Content rendering anomalies after the landing of bug 130078
(Reporter)

Updated

8 years ago
Duplicate of this bug: 591774
Also happens with the Echofon statusbar panel item open.

Open the panel, leave it open, scroll the current page, close the panel, and the area where the panel used to be still holds the pre-scrolled page contents until you scroll the page some more, triggering a repain.
(Assignee)

Updated

8 years ago
Duplicate of this bug: 591834
I'm inclined to think this should probably be a beta5 blocker.

tn, roc, is there something we could do about it quickly?
Summary: Content rendering anomalies after the landing of bug 130078 → [Windows-only] Content rendering anomalies after the landing of bug 130078
Marking as a b5+ blocker for now. This is obviously a blocker, depending on how widespread it is might block this beta or another.

From what I can tell this affects anytime we shift the content window around, right? Do we know if there are other ways to trigger it?
blocking2.0: ? → beta5+
(In reply to comment #8)
> From what I can tell this affects anytime we shift the content window around,
> right? Do we know if there are other ways to trigger it?

If bug 591895 is the same it also appears all the time for me when showing the menu bar while the add-ons manager is open. Also hiding/showing the navigation bar produces the same behavior.
Blocks: 591895
(Reporter)

Comment 10

8 years ago
Created attachment 470467 [details]
bookmarks sidebar quirk
Why is this marked Windows only? I'm seeing it on OSX as well, but it redraws away quickly. Does it redraw away on Windows, as well?

Comment 12

8 years ago
(In reply to comment #11)
> Does it redraw away on Windows, as well?

Not in my experience.  In the sidebar case, you have to close the sidebar; and even then, you are still left with a thin strip that goes away only if the screen is force to redraw (by e.g. scrolling, refreshing, etc.)
Well, that's redrawing :) I'm also seeing some chrome anomolies on OSX, will file another bug on those.

Still looking for a good list of triggers for this; bookmarks sidebar is one, menuBar is another (although I could only get that to happen with about:addons, not with any content page) ... anything else? Do we see it with random scrolling?
Assignee: nobody → tnikkel
(In reply to comment #13)
> Well, that's redrawing :) I'm also seeing some chrome anomolies on OSX, will
> file another bug on those.

chrome-jittery-rendering is now being tracked in bug 592068
(In reply to comment #13)
> anything else? Do we see it with random scrolling?

(In reply to comment #5)
> Also happens with the Echofon statusbar panel item open.
> 
> Open the panel, leave it open, scroll the current page, close the panel, and
> the area where the panel used to be still holds the pre-scrolled page contents
> until you scroll the page some more, triggering a repain.

I think it's any panel with noautohide set to true. (Maybe also noautofocus?)
(Assignee)

Comment 16

8 years ago
I'm just looking into the sidebar issue specifically right now.

So it seems the problem is when the shrinking of the width of the content document causes it to change the position of things on the page. A portion of the page on the left and the width of the sidebar doesn't seem to get invalidated and draws the page as if the width hadn't changed.

Temporarily removing the container layer for the content document fixes the problem. (This is of course not a solution.)
(Assignee)

Comment 17

8 years ago
Applying the patches for bug 579323 fixes the problem for me. So I think we should just take those patches.

Comment 18

8 years ago
I noticed some cases of bad rendering when viewing images that are to large to fit on the screen (and using automatic image resizing).

1) Switch to full screen (press F11)
2a) Move your mouse to show the location bar
or
2b) Leave full screen (press F11)
=> image is displayed wrong / shifted parts
=> http://a.imageshack.us/img203/7103/bug1s.png

1) Switch to full screen
2) Open Tab Candy ("Group Your Tabs")
3) Switch to a different tab group or create a new one
4) Leave full screen
5) Open Tab Candy
=> incorrect thumbnails
=> http://a.imageshack.us/img203/781/bug2l.png

Are these rendering issues the same as this bug?

Comment 19

8 years ago
(In reply to comment #17)
> Applying the patches for bug 579323 fixes the problem for me. So I think we
> should just take those patches.

Does it also fix the cases I mentioned in comment 18?

Updated

8 years ago
Depends on: 579323
579323 has landed, so this should be fixed according to comment #17.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.