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

RESOLVED WORKSFORME

Status

()

defect
--
major
RESOLVED WORKSFORME
9 years ago
10 months ago

People

(Reporter: lucas.werkmeister, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(5 attachments)

Reporter

Description

9 years ago
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

9 years ago
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

9 years ago
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

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

Comment 4

9 years ago
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

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

Comment 6

9 years ago
(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?
Reporter

Comment 7

9 years ago
The problem still occurs with the newest Minefield.
Reporter

Comment 8

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

Comment 9

9 years ago
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")
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED

Comment 10

9 years ago
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 12

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

Comment 13

9 years ago
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*
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Reporter

Comment 14

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

Comment 15

9 years ago
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.
Reporter

Comment 17

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

Comment 18

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

Comment 19

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

Comment 20

8 years ago
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!
Reporter

Updated

8 years ago
Severity: normal → major
Reporter

Comment 21

8 years ago
There is now a problem also when switching TO full-screen. This is ridiculous.
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.
Status: UNCONFIRMED → NEW
Component: General → Layout: View Rendering
Ever confirmed: true
QA Contact: general → layout.view-rendering

Updated

8 years ago
Summary: With returning from full screen on garfield.com (Adobe Flash) site scrolls down only partially → With returning from full screen on garfield.com (Adobe Flash) site does not repaint properly

Updated

8 years ago
Duplicate of this bug: 643865
There are also some pretty bad redraw problems on youtube's progress meter as well.
This is bad. Could use a regression range, but it's probably not hard to just debug. Who wants it?
Related to bug 628897 maybe?
Reporter

Comment 27

8 years ago
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.
Component: Layout: View Rendering → General
(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.
I can confirm that backing out bug 601547 fixes the problem.
Fixes the garfield site too.
Blocks: 601547
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.
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.
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.
Component: General → Layout: View Rendering
Note, bug 634586 is acting as a work around for this. I'll keep this open for the time being though.
Reporter

Comment 35

7 years ago
I think this is fixed now.
Status: NEW → RESOLVED
Closed: 9 years ago7 years ago
Resolution: --- → WORKSFORME
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.