Closed Bug 225057 Opened 21 years ago Closed 18 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: 20 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: 20 years ago → 18 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: