529.36 KB, image/png
509.46 KB, image/jpeg
464.86 KB, image/jpeg
406.16 KB, image/jpeg
344.55 KB, image/jpeg
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.
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.
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.
You shouldn't have to scroll to repaint Flash, so this is an issue.
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.
Just wanted to add that Full-Screen to Normal and back with Flash content works just fine with 3.6.13.
(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?
The problem still occurs with the newest Minefield.
Just got the new Beta 9 and the problem is FIXED. Repeat: Completely FIXED.
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
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.
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
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 → ---
just wanted to add that the problem still occurs with firefox 4 beta 10 and with 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.
Another screenshot of the bug. URL to reproduce: http://armorgames.com/play/5351/this-is-the-only-level-too
This screenshot shows how attachment#3 [details] [diff] [review] should actually look, produced by scrolling to bottom and back again.
The bug does not occur on all flash pages, though, e.g. http://apps.facebook.com/blitzthroughtime/ looks fine.
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
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!
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
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
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?
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.
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.
Note, bug 634586 is acting as a work around for this. I'll keep this open for the time being though.
I think this is fixed now.
Status: NEW → RESOLVED
Closed: 9 years ago → 7 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.