624258 - With returning from full screen on garfield.com (Adobe Flash) site does not repaint properly

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Lucas Werkmeister]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: Firefox 4.0b8

FACT:
I read comics on garfield.com (e.g. http://www.garfield.com/comics/todayscomic.html ) in full-screen. When returning from full-screen to normal mode, the page is partially scrolled down (to make place for address bar, tab bar etc.) and partially not. When entering full-screen, the same can be seen while the top of the brower (address bar etc.) is scrolling up, but when this is finished, the page is properly scrolled up again - but not when returning from full-screen. As I hover the mouse over several components of the page on their actual position, they are repainted, and the combination of some components being half covered by themselves, some other only half visible, and others not at all visible, looks pretty weird. The page looks correct after tab change or complete scrolldown, but scrolling only partially down does NOT make it look normal, you have to scroll until nothing of the original content can be seen anymore.
Two screenshots:
http://www.bilder-hochladen.net/files/big/g352-a.jpg
http://www.bilder-hochladen.net/files/big/g352-b.jpg
SPECULATION:
Garfield.com is almost entirely flash, so I think it may be an issue with the Flash Player. Because of this, I checked the first page with Flash that came to my mind.
FACT:
The problem also appears with the video player of YouTube.
SPECULATION:
I do a little bit of programming (in Java), and it looks to me as if repainting the window after every return from full-screen may solve the problem.

Reproducible: Always

Steps to Reproduce:
1. Open http://garfield.com/comics/todayscomic.html or any other comic on the site
2. Toggle fullscreen on and off again
3. Move the mouse over several items
Actual Results:  
The page looks weird, as described above.

Expected Results:  
The page should have scrolled down a bit and look normal.

Comment 1

[Chris B.]

I went to Garfield.com and notice flickering during repaint of the Flash content during scrolling.  However, I am using the 1/9/11 Minefield build and only noticed a small white line appear in the middle of the comic and not the entire menu off-shift as shown in the screenshots when I go in and out of full screen.  When I go back and forth from full-screen to normal mode, the small white line appears, but disappears when scrolling a bit.  I am not experiencing the menu off-shift at the bottom of the comic.

Comment 2

[Chris B.]

You should always try to post bugs with the latest Minefield (http://nightly.mozilla.org/) and not an official beta build, as there were some Flash rendering / scrolling bugs that were fixed between Beta 8 and today.  Try downloading the official Nightly and report an update.  Don't worry about the software being buggy - I have been using the Nightlies daily since the beginning of October 2010 for all of my web browsing and have not had any major issues with the software, such as crashing or sites not loading, etc.

Comment 3

[Chris B.]

You shouldn't have to scroll to repaint Flash, so this is an issue.

Comment 4

[Chris B.]

I'm experiencing the repaint Flash issue when switching from full-screen to normal mode on ALL sites that use Flash.  Full-screen back to normal mode all Flash content is offset.  You then have to scroll to have Minefield repaint the screen.

Comment 5

[Chris B.]

Just wanted to add that Full-Screen to Normal and back with Flash content works just fine with 3.6.13.

Comment 6

[Chris B.]

(In reply to comment #5)
> Just wanted to add that Full-Screen to Normal and back with Flash content works
> just fine with 3.6.13.

This makes me wonder..........How can a feature work just fine in 3.6.13 but break using the latest Minefield?  This has occurred with other bugs with 4.0 as well.  Don't you recycle source code like a lot of other software developers do?  Do you think Apple, Microsoft, and Oracle code each iteration of their software programs from scratch again?

Comment 7

[Lucas Werkmeister]

The problem still occurs with the newest Minefield.

Comment 8

[Lucas Werkmeister]

Just got the new Beta 9 and the problem is FIXED. Repeat: Completely FIXED.

Comment 9

[Lucas Werkmeister]

Do I have to mark it as "resolved" now or is that something completely different? (I´m not a native english speaker, and according to leo.org "resolved" is not quite the same as "solved")

Comment 10

[Chris B.]

I am still seeing the problem when switching back and forth from full screen and non full screen using F11 and the 1/15 Minefield.  See attached screenshot.

I have to scroll a little to have the page redraw, which I shouldn't have to do.  Once the application goes from non full screen, to full screen, then back, all elements should automatically refresh without scrolling required, so I recommend this bug remain open.

Comment 11

[Chris B.]

Attachment: 1/15/11 Minefield - Went to Full Screen and Back (Need to scroll to redraw Flash elements)

Comment 12

[Chris B.]

I see the problem mentioned in my comment 10 on other Flash sites too, when switching from non to full screen and back, such as:
http://games.latimes.com/index_crossword.html?uc_feature_code=tmcal

Comment 13

[Lucas Werkmeister]

What the -? Now garfield.com looks strange again... i could swear it looked completely normal yesterday and i´m using the same f4b9 as yesterday...? o_O on youtube the problem yesterday also didn´t occur and today it does ?._.? *very confused*

Comment 14

[Lucas Werkmeister]

just wanted to add that the problem still occurs with firefox 4 beta 10 and with latest minefield.

Comment 15

[Lucas Werkmeister]

Attachment: Screenshot showing the problem in latest Minefield.

This image shows that the problem still occurs, and on an, if I might say, pretty prominent page. It also shows that it got WORSE: Going TO full-screen was no problem when I first noticed it. But you can clearly see THREE video progress bars.

Comment 16

[Lucas Werkmeister]

Attachment: Another screenshot showing the problem in latest Minefield.

Another screenshot of the bug. URL to reproduce: 
http://armorgames.com/play/5351/this-is-the-only-level-too

Comment 17

[Lucas Werkmeister]

Attachment: Screenshot showing how TitOLToo should actually look

This screenshot shows how attachment#3 [details] [diff] [review] should actually look, produced by scrolling to bottom and back again.

Comment 18

[Lucas Werkmeister]

The bug does not occur on all flash pages, though, e.g. http://apps.facebook.com/blitzthroughtime/ looks fine.

Comment 19

[Lucas Werkmeister]

Attachment: Screenshot showing six copies of an element in flash

This screenshot was produced by toggling full-screen on and off repeatedly. At the end, the whole game screen is filled with six copies of the content below. (Except for the eye, which is part of the game and blinks, which is probably why it is visible)
http://armorgames.com/play/10259/blow-things-up

Comment 20

[Lucas Werkmeister]

Seriosly, is ''anyone'' working on this? Or even just has it in mind? I mean, flash player is a major part of the internet, and full-screen is a commonly used tool, and if they don´t work together, I´d consider this a serious problem!

Comment 21

[Lucas Werkmeister]

There is now a problem also when switching TO full-screen. This is ridiculous.

Comment 22

[Jim Mathies [:jimm]]

Switching to layout, but this might be graphics or widget as well.

I can confirm the bug - open

http://garfield.com/comics/todayscomic.html

go in and out of full screen a couple times. Page /plugin content become garbled.

Comment 24

[Jim Mathies [:jimm]]

There are also some pretty bad redraw problems on youtube's progress meter as well.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is bad. Could use a regression range, but it's probably not hard to just debug. Who wants it?

Comment 26

[Timothy Nikkel (:tnikkel)]

Related to bug 628897 maybe?

Comment 27

[Lucas Werkmeister]

Timothy: I think bug 628897 is actually another duplicate of this (or the other way around, I haven´t looked at the dates), the steps to reproduce look similar to me. The reason why not the complete video is shifted, I think, is that the video has to be repainted all the time (else it wouldn´t be video but merely an image) and this repaint works at the correct location. See also attachment 512167 [details] (last one of this bug), I think the blinking eye has just the same effect.

Comment 28

[Jim Mathies [:jimm]]

(In reply to comment #26)
> Related to bug 628897 maybe?

Hmm, not having much luck reproducing that.

(In reply to comment #25)
> This is bad. Could use a regression range, but it's probably not hard to just
> debug. Who wants it?

I'm at adobe today, can't help much till I get back.

Comment 29

[Jim Mathies [:jimm]]

I can confirm that backing out bug 601547 fixes the problem.

Comment 30

[Jim Mathies [:jimm]]

Fixes the garfield site too.

Comment 31

[Jim Mathies [:jimm]]

Hmmph, I don't see why this is breaking plugins. The starved paint routine has always ignored windows that weren't nsIWidget windows so flash gets skipped. Odd that adding an Update to the parent broke painting in a child. MSDN doesn't mention anything about UpdateWindow cascading down either.

Comment 32

[Jim Mathies [:jimm]]

I guess the addition of UpdateWindow on the parent messed things up, since DispatchPendingEvents was a no-op before we added that. Not sure why that is yet though.

Comment 33

[Jim Mathies [:jimm]]

So, this update is preventing an invalidation on our plugin window for some reason. Without the patch applied, we receive an onpaint for the plugin window with a rect equal to the entire window. That in turn calls over to the child process via CallUpdateWindow for painting. With the patch the invalidation never occurs and the plugin never gets the repaint.

I haven't really had a chance to dig much deeper from here - I'll be back at my desk late tomorrow or friday.

Comment 34

[Jim Mathies [:jimm]]

Note, bug 634586 is acting as a work around for this. I'll keep this open for the time being though.

Comment 35

[Lucas Werkmeister]

I think this is fixed now.