Closed Bug 225057 Opened 21 years ago Closed 19 years ago

windows don't redraw after hiding

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: fredct, Assigned: bugzilla)

References

Details

Attachments

(5 files)

Non redrawing window behind redrawing window after being unhidden.
162.94 KB, image/jpeg
Details
Non redrawing window in front of redrawing window after being unhidden.
127.29 KB, image/jpeg
Details
Non redrawing window alone after being unhidden.
120.38 KB, image/jpeg
Details
Demonstrates the bad window redraw bug after hide and show
155 bytes, text/html
Details
Page with bad java applet, using <object> tag
186 bytes, text/html
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7 I'm used to my bugs being dups, but I really do search. Maybe this one is new :-). With Firebird 0.7.1, when I hide Firebird using command-H or option-click, then when I bring it back to the front by clicking on it in the dock (re-exposing it), the multi-tab window is completely blank. Anything that redraws it will make it 'reappear', be it moving another window over it, moving it behind the dock, or clicking the upper-left button to hide the toolbars. The former two only redraw the effected portion, why the last one redraws the whole window. Single-tab windows appear to never be effected by this. FYI, I have it set to not show the tab bar if there's only one tab. This behavior is pretty consistent, but not 100%. Sometimes it won't happen, but usually if I switch around between tabs and try again, it will then occur. Reproducible: Sometimes Steps to Reproduce: 1. Open a window and load multiple web pages in different tabs. 2. Hide it by command-H or option-clicking off of it 3. Click on it in the dock to reveal it - notice that the window is completely blank 3b. If it didn't go blank, move between tabs a bit and try again. It happens, 90% or the time or so. 4. Click the Toolbar-hide button on the upper left and the window redraws... or make it redraw some other way Actual Results: Self-explanatory Expected Results: Self-explanatory
i'm not seeing this, 20031104. are there specific sites that cause you problems?
Fixed in 11/9/03 Sorry. :-) Though I did find a themes issue which I'll report.
Wait, I take that back, I just made it happen again, and now it's happening reguarly. For your reference, I have one window with this page open. I have a second window with 4 tabs - www.thehungersite.com, elf.elynah.com, blogforamerica.com, and uscho.com . But now that it's started happening again, it even happens with just those first two.
i'm still not seeing this, even with the exact sites you list. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031215 Firebird/0.7+ have you seen this with a more recent build?
WFM on Gecko/20031212
I see an identical bug using Mozilla: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 running under Panther (OS X 10.3.2). It nearly happens frequently, and doesn't seem to matter which sites are loaded.
Mac OS X 10.2.8 Firebird Version: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040127 Firebird/0.8.0+ Using the sites in comment #3 and following the reproduction instructions; I am not able to reproduce this bug.
WFM 10.3.3 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040413 Firefox/0.8.0+ Redraw takes a few seconds on my system (lots of windows open)... and lots of tabs Also Fred you might be happy to know someone finally duped you... see bug 233749
Fred, can you reproduce this problem using a new Firefox user profile?
never seen this, now using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040425 Firefox/0.8.0+ --> wfm
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
*** Bug 244635 has been marked as a duplicate of this bug. ***
*** Bug 257387 has been marked as a duplicate of this bug. ***
Please reopen this. I'm still seeing this with 0.9. I'm attaching screen shots. The first is the window that doesn't want to redraw upon being unhidden behind one that does (screen_back.jpg). The second is the same two windows, only this time the one that doesn't want to redraw is in front (screen _front.jpg). The third is the cranky window alone (screen_solo.jpg). The cranky window has been open a while, but less than a day. By the way, the regions that are redrawn in the faulty window are from where the Command-Tab switching overlay or the Grab screen capture window were before the screenshot was taken, but after Firefox was unhidden.
I'm happy to try to serve as a QA resource for this bug, but it currently is *not* fixed in any released version since it was filed. Fred (or another), can you please reopen (I don't have permission).
*** Bug 257941 has been marked as a duplicate of this bug. ***
Still happening with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040904 Firefox/1.0 PR (NOT FINAL) and Mac OS 10.3.5. Please re-open.
Still happening with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040907 Firefox/1.0 PR (NOT FINAL) and OS 10.3.5.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I've found that when I first install the new build it will work fine for a day or so. If I leave the browser open for over a day, then it starts to have the re-draw problem when coming out of hide. And something else I've noticed is that if I hide the browser while on this tab (http://bugzilla.mozilla.org/show_bug.cgi?id=225057) and I un-hide it, it redraws perfectly fine. With any other web site, it won't re-draw correctly.
Just downloaded Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10, and it didn't even take an hour of having the browser up for the redrawing issues to begin.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3 Mac G5 dual 1.8 OS X 10.3.5 Great rendering speedbut this elementary bug renders Firefox completely useless.
I'm also seeing this same behavior with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10. G5 dual 2.0Ghz, 10.3.5. I'm willing to help debug.
I am still experiencing this bug as of 20/01/2005. I am using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041110 Firefox/1.0 (PowerBook) on a PowerBook G4 running Mac OS X 10.3.7. I also experienced this bug with the official 1.0 version of Firefox for Mac OS X. This is the most annoying bug I've experienced so far with Firefox under Mac OS X.
I'm having the same problem. I am using Mac OS X 10.3.8 and Firefox 1.0.2. I have my computer set to hide all background applications. If I have several tabs open (more than 5-7), and I switch back to Firefox from another application, I can't see any window interface elements at all. In order to get the window (and contents) to draw properly I find myself using expose. This forces the window to redraw.
The people who are still seeing this bug: - are you using any third party extensions or plugins? - any ad blockers? - any themes? I didn't see any mention of this stuff being considered, so I thought it was worth checking. I've certainly never seen this bug. cheers
*** Bug 298205 has been marked as a duplicate of this bug. ***
Using the nightly builds, this had disappeared for a while on my side, but the last two weeks, I've been experiencing this problem randomly again. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050711 Firefox/1.0+ (PowerBook) (In reply to comment #27) > The people who are still seeing this bug: > - are you using any third party extensions or plugins? > - any ad blockers? > - any themes? Personal theme (modified version of Aaronnax GrapplePro theme), very few extensions (Live HTTP headers, LoremIpsum generator). Ad blocking via userContent.css. Happens mostly when I have my own sites open, pages where I'm working on. Switching between text editor and Firefox. Nothing in my UserContent.css can affect those pages. 3-4 tabs open on average. If I recall correctly, I've had the problem with the default theme as well.
How infrequent is "randomly"? As in, is it frequent enough that you could disable all your third-party stuff, start a fresh profile, and expect the bug to reappear within a reasonable amount of time if it's going to at all? And does anyone else who experiences this bug have anything in common with the third-party things that Philippe listed? cheers :)
(In reply to comment #30) > How infrequent is "randomly"? As in, is it frequent enough that you could > disable all your third-party stuff, start a fresh profile, and expect the bug to > reappear within a reasonable amount of time if it's going to at all? Let me see. Randomly, as not happening every day or every browsing session. But it has happened at least 3 or 4 times in the past two weeks. I experience the bug today. I had installed the latest nightly build in the evening, and put the Powerbook to sleep without quiting Firefox. While working on a number of html/php/css files, going back and forth between Fx and code editor, the problems happens. Firefox in front, command-H to hide, edit something in text editor, command-tab to get Firefox back to the front is my usual way of working. But it only happened after an amount of time (2 hours working, I guess). I didn't experience those problems two days ago, with a similar workflow. The only two things that are constant: Firefox open for a prolonged amount of time, and a browsing session with a long(er) history. I'll try to keep an activity log I upgrade Firefox daily, and usually sanitize (clean cache, forms, history, ..) before installing the next nightly. Note: a few more bugs that are dupes I think: bug 297216 and bug 276045.
All I can suggest is trying to reproduce it with all those extensions, ad-blocking and non-standard theme off. And then if that fixes it, gradually re-adding them till it comes back. Or you could try just switching off one thing at a time for a couple of days. Also try with a truly fresh profile by temporarily removing <home folder>/Library/Application Support/Firefox so it has to create a new one. In this situation, it's a shame that it doesn't occur more frequently, though.
(In reply to comment #32) > In this situation, it's a shame that it doesn't occur more > frequently, though. Sorry it took so long to come back on this. The randomness of the problem is a problem in itself. Since I last posted (comment 31) a did run quite a bit of testing. The profile I use is about two weeks old. During this period I've updated daily to the latest nightly build. I always fetch them in the evening (my timezone) - and perform the following steps: * download * sanitize browser (Tools > Sanitize): clearing Cache, History, Download History, Saved Form Information. * quit browser and switch to new version. [1] For 4 days, using my profile (theme, extensions, userContent.css), I made sure to *quit* the browser before putting the computer to sleep for the night (Apple menu > Sleep). I haven't had any painting problems during those days. [2] Next 3 days of testing: a new profile, but moved my bookmarks file, passwords, cookies.txt, prefs.js. Default theme. One extension (Live HTTP headers). Same as above [1], quit browser before putting computer to sleep. No problems. [3] Next 3 days, same profile as in [2] above, but this time *not* quiting the browser before putting the computer to sleep overnight. During those 3 days, I could reproduce the painting problem: while switching to/from email client, while switching between text editor and browser - following the steps in comment 31. 4 or 5 tabs open, each with a browser history. Problem started to happen after about 3 hours of using the browser. It only happened on two of the 3 days. The only constant in this is not quiting the browser when manually putting the computer to sleep.
The movie linked from bug 297216 comment #4 illustrates quite well what I've experienced randomly. (and a note: I haven't experienced this bug since my last comment above, using the latest nightly trunk builds).
I can reproduce this quite easily with a fresh profile: Launch Deer Park with a brand new profile. Go to http://www.dslreports.com/stest?loc=97 and wait for the Java applet finishes loading. Hide Deer Park. Then click Deer Park icon in the Dock. The window comes up blank. Note no tab is involved here. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050804 Firefox/1.0+
Finally, I can reproduce this bug, using Stephen's test case! Although that's not due a multi-tab bug, so part of me worries that there are two different phenomena that are causing a similar effect. I've reduce Stephen's page to a really simple test case. In essence, nothing more than an empty applet, which generates a java.lang.NullPointerException. I'll post it next, in order to demonstrate. I can also say that it's existed since at least 2003, and in Seamonkey too. Anyway, can you guys who reported the "multi tab" effect confirm or deny that all cases had either a bad applet or a java.lang.NullPointerException in one of the pages? Maybe that's been the case all along? If not, the java-related bug should probably be posted as a separate bug. Also, can someone with better coding skills than me find other ways (than the bad/empty applet) of generating a "java.lang.NullPointerException" as test cases? I have no idea where to start. cheers
Summary: multi-tab windows don't redraw after hiding → windows don't redraw after hiding
The attachment has nothing more than an empty applet. Open the attachment in a new window, wait till it gives the java error, hide it, then show it again. Window, including toolbars and scrollbar, should be blank.
Followed Wayne's instructions, except I opened the link as a new tab, and reproduced the bug. To add, once I closed that particular tab, I hid firefox. When I brought it back up, it redrew perfectly.
(In reply to comment #37) I can reproduce the problem with that applet (opening in a new tab and opening in a new window). I have multiple tabs open. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050806 Firefox/1.0+ ID:2005080610 I'm not sure if this is the whole story though. I've been experiencing those problems with no more than plain html pages loaded.
Attaching another test case. This time using the <object> tag instead of the <applet> one, since the latter is supposed to be on the way out. Using 'classid="java:"' it does the same thing, though... basically creates a bad java event. And indeed it does cause the same redraw issue after hiding. I've tried to create bad embedded objects using other types of classids or data paths, but I haven't been able to reproduce the bug with those so far. But then again, my knowledge of html is severely limited. So if anyone wants to modify this test case to try and reproduce the bug without using a java applet, that would be great!
Finally, I should also add that once a window has suffered this bug, then subsequent pages that you visit in that window can also show the redraw after hide problem. So an innocent page could show symptoms simply because you ran across a bad applet earlier. Closing the window and opening a fresh one will avoid this. Please keep this in mind when troubleshooting. If you guys really can reproduce this bug in: -a fresh page -with no signs of bad code or applets -and no third party extensions or themes -and in a recent trunk build then I'll assume the java applet issue is a different bug that causes the same symptoms, and open a new bug for it. Thanks!
(In reply to comment #41) > Finally, I should also add that once a window has suffered this bug, then > subsequent pages that you visit in that window can also show the redraw after > hide problem. So an innocent page could show symptoms simply because you ran > across a bad applet earlier. Closing the window and opening a fresh one will > avoid this. That could be an explanation. I rarely close the browser window during the course of the day (working in single window mode). It is then possible that a page containing a badly coded part could cause the bug, without it being triggered at the moment that [bad] page is loaded. Like something that gets stuck in the history of the window. The BBC news site, which I visit daily, has a (javascript) newsticker on top of the page, loaded via an iframe, I just tested this: open the content of that iframe in a new tab; hide/show the browser. Sure enough half of the window turned blank. Other possible offenders: ad banners, particularly Flash ones. Advertisers are not exactly known to serve their content via valid code. I don't see them often, as most are blocked on my side, but sometimes there is one that sneaks through.
Hey Philippe, Is the ticker you're referring to: http://news.bbc.co.uk/nol/ifs_news/hi/front_page/ticker.stm ? I opened it in a new tab (attempting to do that seemed to produce its own menu-jumping issues, but that's another story). Unfortunately I couldn't get it to display the bug symptoms, no matter how many times I used hide and show. So I just wanted to check with you that I was using the right ticker. I've also never seen this problem through an ad banner. But if you can find one that reproduces the problem reliably, please let us know.
(In reply to comment #43) > Hey Philippe, > > Is the ticker you're referring to: > http://news.bbc.co.uk/nol/ifs_news/hi/front_page/ticker.stm > ? Yes, that is the one. I just tested again, and now it works correctly. Now, it is possible that there was some influence from running you latest java test (comment #40). I did the BBC test in the same window. I've since quit the browser and relaunched (for unrelated reason). > > I opened it in a new tab (attempting to do that seemed to produce its own > menu-jumping issues, but that's another story). I had the same menu jumping issues on my side. Weird one. > > I've also never seen this problem through an ad banner. But if you can find one > that reproduces the problem reliably, please let us know. I'm a bit speculating there; you create a test with an java applet (which caused problems), but a java applet is something I don't encounter often in my daily browsing. Hence my thoughts about iframes and object tags, which are often used to load ad banners. And as I've pointed above in previous comments (comment #31 and 33), the problem in this bug only happens randomly on my side.
*** Bug 297216 has been marked as a duplicate of this bug. ***
I'm beginning to think that Java applets may be the ultimate cause of all the cases here. I think the reason that a lot of people have reported sleep as the issue is because that sleep seems to kill some Java applets. For example, in the duplicate bug 297216, the test case given by Chris is http://crisp.cit.nih.gov/ That page has a little Java scroller/ticker. I can't reproduce the symptoms with that page immediately, but if I put the computer to sleep, the applet seems to stop working (and stops bleeding through tabs, which is the result of another bug). After that, the redraw problem begins. This means that the page doesn't need to contain an obviously bad Java applet. Just an applet that might break under certain conditions (such as computer sleep). So the question remains, can anyone reproduce this without opening a page with a Java applet, or at least having visited one somewhere in their current window history (that could have potentially broken)?
At the risk of being spammy, I should mention another possible link to Java applets. At least in some cases, if you have an applet running fine in one tab, and then close that tab, then it causes the redraw bug in other tabs, even though the applet was running fine. This could cause a lot of the cases seen here, and explain the reason that many people have only noticed it in multiple tabs. As an example: - In a new window, go to: http://www.mozilla.org/quality/browser/front-end/testcases/oji/test1.html - Then open a second tab. You can even leave the new tab blank (you'll see the applet draw through onto the blank page, though, due to bug 162134). - Hide and show the window a few times, but there shouldn't be any redraw problems. The applet should continue to run fine. - Then close the tab containing the applet. - Hide and show the window a few times and you should see the redraw bug.
*** Bug 276045 has been marked as a duplicate of this bug. ***
Is anyone still seeing this bug? The Java-related error, at least, seems to now be fixed for me. I presume because of our new Java plugin.
This seems to have been fixed in v1.5
Resolving then. Please reopen if anyone can still reproduce it.
Status: NEW → RESOLVED
Closed: 21 years ago → 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: