Closed Bug 305970 Opened 19 years ago Closed 19 years ago

Certain UI operations (opening dialogs, drag and drop) cause refresh, prolonged hang (CPU at 100%)

Categories

(Core Graveyard :: GFX: Gtk, defect, P1)

x86
Linux

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9alpha1

People

(Reporter: dennisml, Assigned: dbaron)

References

Details

(4 keywords, Whiteboard: [patch])

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050825 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050825 Firefox/1.0+

Selecting "Save Image As..." behaves weird when selected the first time after
starting firefox. (redisplays top of page and context menu while dialog is open)

Reproducible: Always

Steps to Reproduce:
1. Start Firefox
2. Load a page with an image
3. Right-click image and select "Save Image As..." from the context menu
Actual Results:  
Within a second the following happens:
1. The save dialog is displayed
2. The page disappears
3. The page gets displayed again but scrolled all the way to the top
4. The context menu gets displayed again but does not react to moving the
pointer over it or clicking a button

The image can be saved or the dialog can be cancelled and both dialog and
context menu will disappear and Firefox will continue to function normally.
After this any further attempts to use "Save Image As..." work fine.

Expected Results:  
No redisplay/scroll-up of page and the context menu shouldn't pop-up again.
Can you reproduce this in a clean profile? Also, what version of GTK are you
using? This sounds kind of similar to bug 304983.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050825
Firefox/1.6a1 ID:2005082521

WFM both in branch and trunk.
(In reply to comment #1)
> Can you reproduce this in a clean profile? Also, what version of GTK are you
> using? This sounds kind of similar to bug 304983.

Yes, I can reproduce this with a clean profile and I'm using gtk-2.8.0 (from
Fedora Core Rawhide). Before filing this bug I searched for similar ones but
only found crashing and freezing bugs. The effect in this bug only happens once
and you can still save the image it's just that Firefox does some weird UI
things after popping up the dialog.
I did a bit of experimentation and made two observations:

1. If the page fits in the window (so that you don't get a scrollbar) then the
page redrawing doesn't happen but the context menu problem persists.

2. If I insert an iframe into the page that contains an image then selecting
"Save Image As..." on that image does not show the same problem.
Dennis, is this still an issue after updating gtk and cairo?
(In reply to comment #5)
> Dennis, is this still an issue after updating gtk and cairo?

I'm still running cairo 1.0.0 and gtk 2.8.0 since there haven't been new
versions in Rawhide so far.

After some additional tests the behaviour I see looks like this:

For each open window if *any* tab in that window shows a page that doesn't fit
in the browser-window (ie it has a scrollbar) then *all* tabs in that window
redisplay their pages scrolled all the way to the top.
More info:

I've updated to gtk2-2.8.3 but see no change in behaviour.

When I saved an attachment in Thunderbird I noticed that it is affected by the
context menu problem too. There is a difference between versions though, in a
nightly build dated 20050723 the context menu popped up again and was usable
whereas in a more current build from yesterday the menu just popps up but no
entries are selectable (just as in firefox).
Is there a way to get older nightlies from somewhere (from the last few months)?
If so I could try to pinpoint when this problem started to appear.
The bug appears in trunk build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050429 Firefox/1.0+. The builds from the 28th and before do not show
this problem.
I just noticed that the "scoll to the top" effect also occurs when I start
dragging the icon from the address bar.
Flags: blocking1.8b5?
not going to block on this but if we get a low-risk fix, we'd consider it.
Flags: blocking1.8b5? → blocking1.8b5-
I did check a few additional areas of Firefox looking if they are affected by
this or not in order to help whoever might look into this and summed up all of
the information:

Triggers:
    - Start Drag&Drop on any item (happens right after you start to drag)
    - Invoke a GTK FileChooser in any way
    (could this indicate a firefox<->gtk interaction issue?)
 
Effects:
    (reset = pane gets completely redrawn and scrolled all the way to the top)
    - All tabs in all windows get reset (!)
    - "View Source" window get reset
    - History sidebar gets reset
    - Bookmark sidebar gets redrawn but *not* scrolled all the way to the top (!)
    - Bookmark manager and the "Media Preview" pane in "Page Info" don't seem to
be affected

Versions:
    - OS: Fedora Core Rawhide
    - Firefox: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20050922
Firefox/1.4
    - Gtk: gtk2-2.8.6-1 (from current Rawhide)

Bug shows up for the first time in the build: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8b2) Gecko/20050429 Firefox/1.0+.

I wonder if it is a coincidence that this is the first build that had a rather
non-trivial patch applied for bug 289940 (Chrome code needs to be protected from
untrusted events).
The patch for Bug 240276 (Reorganize nsGfxScrollFrame) that was check in on that
day looks light it might be the cause too.

I also tested the new firefox-1.5-0.5.0.beta2 package in rawhide and it shows
the same problem as the mozilla.org nightlies.
Dennis, since you're the only one that seems to be seeing this, we're going to
need your help tracking down the problem. Let's just focus on the issue of the
"Save As" dialog messing up. Could you grab a build before and after those two
patches went in and see if you see any difference in the behavior? Also, I think
it'd be best you do the testing in a clean profile.
Severity: normal → major
Version: unspecified → 1.5 Branch
After a bit of experimenting I was able to create some custom builds (there were
some linking problems) with the following results:
2005-04-28 14:50 => bug does not show
2005-04-28 15:00 => bug does show
(times are already converted to the timezone of bonsai.mozilla.org)

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-28+14%3A50&maxdate=2005-04-28+15%3A00&cvsroot=%2Fcvsroot

This seems to identify bug 240276 as the cause.
I'll take your word for it, Dennis. Someone probably needs to figure out what
component this needs to go in.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Blocks: 240276
I'll move it to Core/Layout since that's where bug 240276 lives and it's a
better match than Firefox/Menus.
Component: Menus → Layout
Product: Firefox → Core
Version: 1.5 Branch → 1.4 Branch
I just upgraded the gnome-themes package and after that the following happened:
I clicked the "Applications" menu on the gnome-panel, the menu opened but
without the icons, the harddrive thrashed for about half a second, the page
displayed in Firefox got "reset" to the top, all icons on the panel flashed and
the icons in the Applications panel menu appeared. I tried downgrading the
package and installing it again but I was unable to reproduce this.

It seems this really is a gtk problem where gtk emits some kind of event and
that the changes in the patch for bug 240276 make Firefox sensitive to that event.
It is also peculiar that all three ways to trigger this (applications panel
menu, dragging of icons in firefox, popup of gtk file chooser) seem to involve
the rendering of icons in some way.
I'm seeing this too, on two different Fedora Core 4 systems (so I'm not on the
absolute bleeding edge).  I've been meaning to submit a bug report for a while,
but only just got around to it.  Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.8b5) Gecko/20051019 Firefox/1.5 ID:2005101904
I see this in fx and tb, trunk and m1.8branch, gtk 2.6.10-1 (debian).

"Save link as" also does this.

In thunderbird, on first attachment save via context menu, the message pane
blanks and the message is reloaded (scrolls to top) and the context menu
re-appears as the filepicker becomes populated.
Version: 1.4 Branch → Trunk
another trigger: displaying the 'general' or content' pref pane.

the redisplaying of all documents hangs firefox on my (too old, yeah) box for up
to several minutes, if the bug is triggered late enough in the session (plenty
of documents open by then).
Keywords: hang
I can reproduce this in the m.o 1.5b2 release build for the filepicker case, but
not for the prefwindow case; looking at the steps to reproduce, I'd guess this
is because the release does not use gnome stock icons for the prefwindow, but
the native filepicker itself of course does use them.
I can reproduce the issue of the "Save As" dialog messing up.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 ID:2005102514

gtk+2-2.8.3 (Slackware)
So, this bug is apparently not caused by GTK 2.8 because it's been observed in 2.6, too. Layout probably isn't the right component for this...
Keywords: qawanted
QA Contact: menus → layout
I found a way to reproduce this without the need to restart Firefox. Start the Gnome Theme Preferences and select "Theme Details". Now scroll down a bit on a web page in Firefox and select a different color scheme in the "Theme Details" window (i.e. "Clearlooks-Olive", "Clearlooks-DeepSky", etc.). Everytime I select a new color scheme the scrolling happens.

I also noticed that if I do this on gnome-look.org the Google-Ad iframe at the top of the page "marches" to the right for several seconds (it moves to the right several pixels multiple times) and then gets displayed correctly again.
*** Bug 316247 has been marked as a duplicate of this bug. ***
I see this as well. Very annoying.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 (rc2)

GTK+2.8.6 (gentoo)
Flags: blocking1.8.1?
Image somewhat compromised to get below 300Kb (png=>jpeg conversion)
Gnome 2.12.1, Ubuntu 5.10 "Breezy", Kernel 2.6.10
Firefox from Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051110 Firefox/1.6a1
Thunderbird   2005-11-10 trunk
BUG PRESENT in both FFox and TBird.
RE: Comment#13, Occurring in both products very much suggests a [mozilla] <> GTK error.

Annoying as heck, but easily worked around.  Disappears after first "save" and doesn't come back.
The bug hardly has anything to do with saving an image -- there are some other operations that can reproduce it just as well, one of them being beginning a drag-n-drop (DnD) operation. Once either of those operations is performed once and the initial hang is experienced, no more hangs will occur during the session.
Summary: "Save Image As..." behaves erratic the first time it is selected → Certain UI operations (dialogs, DnD) cause refresh and prolonged hang
*** Bug 316872 has been marked as a duplicate of this bug. ***
Summary: Certain UI operations (dialogs, DnD) cause refresh and prolonged hang → Certain UI operations (opening dialogs, drag and drop) cause refresh, prolonged hang (CPU at 100%)
*** Bug 316983 has been marked as a duplicate of this bug. ***
*** Bug 314112 has been marked as a duplicate of this bug. ***
*** Bug 315158 has been marked as a duplicate of this bug. ***
*** Bug 317223 has been marked as a duplicate of this bug. ***
*** Bug 317163 has been marked as a duplicate of this bug. ***
I have the same problem in Ubuntu Linux 5.10 using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051119 Firefox/1.5

@ Asa Dotzler in relation to your comment: not going to block on this but if we get a low-risk fix, we'd consider it.

May I ask why? As I'm sure a bug like this would never make it into a windows version of Firefox. When using xp I've never experienced anything like this, so why is this bug not important enough to fix for linux users? It only seems fair we linux users get the same level of quality.
I get these hangs very frequently while asked for my master password. As I surf certain web pages where I need password authentication daily this is very annoying because in 50% of all cases, firefox becomes unresponsive.
I get this (on a 2.6 Gtk+) when selecting a few lines of text and attempting to drag it. This yields 100% CPU for between 10 and 30 seconds as soon as the drag starts. The text selection colour changes from blue to grey but then stops. After it recovers everything is normal again. Very annoying. Doesn't happen all the time though; can't work out why.
So the problem here is that drag&drop and certain (modal?) dialogs cause style_set_cb (added in bug 238854) to be called, which makes us decide that the GTK theme has changed, so we restyle and reflow every window.  This often happens multiple times.  It seems like this may well be a bug in the way we're using GTK, since using a style change callback to determine that the theme changed and we should restyle everything seems a little suspicous.  But it could also be a GTK bug.  Or both.
Attached patch patchSplinter Review
This switches to a more conservative way of determining that the theme has changed.  It works for me on Fedora Core 4.  I have two basic questions about this approach:
 * how portable is it, both to old GTK versions and future versions?  (...and what could be done to improve that?)
 * is relying on pointer identity of the result of gtk_settings_get_default() safe?
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Attachment #204011 - Flags: superreview?(bryner)
Attachment #204011 - Flags: review?(caillon)
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.9alpha
Tested on JDS 3 and ubuntu 5.10, this patch won't break bug 238854.
*** Bug 313386 has been marked as a duplicate of this bug. ***
*** Bug 307260 has been marked as a duplicate of this bug. ***
*** Bug 309453 has been marked as a duplicate of this bug. ***
Component: Layout → GFX: Gtk
*** Bug 309499 has been marked as a duplicate of this bug. ***
Comment on attachment 204011 [details] [diff] [review]
patch

r=caillon.  Thanks for tracking this down.
Attachment #204011 - Flags: review?(caillon) → review+
(In reply to comment #48)
> (From update of attachment 204011 [details] [diff] [review] [edit])
> r=caillon.  Thanks for tracking this down.

caillon, I remember we discussed this on IRC a while ago (switching from "style-set" to "gtk-theme-name" signals), and you raised the concern that we might not pick up changes to theme properties, but only when the actual theme name changed. I haven't investigated this myself, but thought it might be worth reminding you of it.

Also remember the other issue where, despite the fact that I commented out the style-set signal callback completely and relinked everything, Mozilla still picked up theme changes. Why this happens is still a mystery to me.
I have the same problem :
gentoo, gtk2.8.6, firefox 1.5 rc1

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051109 Firefox/1.5

If i leave it like this for 2-5 min everything goes to normal i.e. FF is not crashing but freezing for 2-5 min (and 100% CPU usage)
Now upgrading to gtk2.8.7 to see if this will help, and then will try FF-rc3.
This is an extremely annoying bug which I'm seeing on Firefox 1.5RC3 on Linux. I sure hope it gets fixed before 1.5 final gets released. This bug is painful...
(In reply to comment #51)
> This is an extremely annoying bug which I'm seeing on Firefox 1.5RC3 on Linux.
> I sure hope it gets fixed before 1.5 final gets released. This bug is
> painful...
> 
gtk-2.6.10, Fedora Core 4, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5.
*** Bug 317929 has been marked as a duplicate of this bug. ***
Same problem (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5), Ubuntu Linux Breezy.

Sometimes this causes the cursor to hang in such a way where I cannot even select other applications, and have to kill Firefox from a VT.
(In reply to comment #49)
> caillon, I remember we discussed this on IRC a while ago (switching from
> "style-set" to "gtk-theme-name" signals), and you raised the concern that we
> might not pick up changes to theme properties, but only when the actual theme
> name changed. I haven't investigated this myself, but thought it might be worth
> reminding you of it.
> 
> Also remember the other issue where, despite the fact that I commented out the
> style-set signal callback completely and relinked everything, Mozilla still
> picked up theme changes. Why this happens is still a mystery to me.

Without any callback, it picks up the color changes and maybe the font changes, but things still aren't right (e.g., the menus move around in odd ways).  This problem doesn't exist with my patch, even when I change just the "Controls" aspect of a theme in the FC4 preferences.  I'm not sure what finer-grained control there is, at least commonly available, and I'd certainly rather err on the side of too little restyling (where we may have a bug with not restyling with certain theme changes) than too much (where we have major performance problems in everyday use).
Attachment #204011 - Flags: superreview?(bryner) → superreview+
Fix checked in to trunk (that's not the 1.8 branch, folks, don't comment here that it's not fixed in 1.8).
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(In reply to comment #56)
> Fix checked in to trunk (that's not the 1.8 branch, folks, don't comment here
> that it's not fixed in 1.8).
> 

I'm using the hourly linux trunk build and I can confirm it is now fixed for me under Ubuntu Linux 5.10 with Gnome 2.12.1
The fix works fine here. Thanks!
Tried the latest nightly, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051129 Firefox/1.6a1, but no go. I still have the problem described in bug 317929 where the browser becomes totally unresponsive after hitting Save until the Download Manager pops up. This typically takes 5-6 seconds. 

Perhaps bug 317929 is not a duplicate of this bug after all?
Flags: blocking1.8.0.1?
*** Bug 318948 has been marked as a duplicate of this bug. ***
I'm glad this fix finally made it in.  It works great and I haven't had the problem since then.  But...

This problem fixed the problem that the theme update function was being called when it didn't need to be.  But why does the function that handles theme updating take so long to redraw the window?  Firefox is the only GTK app I'm running that started eating my processor just now when I actually was looking for a new theme.  Is there a bug relating to how long the function actually takes and/or should one be filed?
*** Bug 319261 has been marked as a duplicate of this bug. ***
*** Bug 319260 has been marked as a duplicate of this bug. ***
Changing the theme forces a relayout of all pages. This can be very slow if you have large and/or complex pages loaded.
*** Bug 318227 has been marked as a duplicate of this bug. ***
*** Bug 319667 has been marked as a duplicate of this bug. ***
My bug report got marked as a duplicate of this one. While I don't think it's exactly the same (as I don't see anything here about the hanging duration increasing with more tabs open) it's somewhat correct as to my problem. 

I've got Firefox 1.5 on FreeBSD 5.4-RELEASE [amd64] (installed via ports) with GTK 2.8.8. I'm wondering where I could find source distfiles that would have this fixed in them to see if it fixes the points I mentioned in my report. I looked at the "nightly" directories but those seem to be just binaries. 

Also, I understand its hard to provide a release date, but is there any rough idea on when it might be fixed in a release? I've been using Firefox since it was Firebird and this is the only problem with it hanging up I've ever had. Unfortunately this one is real bad so if it's going to be a long time, then I may want to look into constantly using the development sources until a new release is made.

Thanks very much.

-Mark

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8)
Gecko/20051201 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8)
Gecko/20051201 Firefox/1.5
*** Bug 319873 has been marked as a duplicate of this bug. ***
Do we know when the update that contains the fix will be released? I couldn't find the release plan for updates anywhere. thanks.
*** Bug 320109 has been marked as a duplicate of this bug. ***
Submitting a screenshot for mainly documentation purposes, as I'm waiting for an update (forced by the browser) to fix this. For some time, I was getting used to the space between where it says 'Mozilla Firefox' (on top) and 'File, Edit, View, etc' just below it... This was happening after the bug shows itself by hanging the browser sometime. Nowadays, the 'close tab' X (right below google toolbar) dissapears. See screenshot.
Comment on attachment 205771 [details]
Firefox slightly defaced due to bug - for documentation

Attachment #205771 [details] has nothing to do with this bug.
Attachment #205771 - Attachment is obsolete: true
*** Bug 320107 has been marked as a duplicate of this bug. ***
(In reply to comment #72)
> (From update of attachment 205771 [details] [edit])
> Attachment #205771 [details] [edit] has nothing to do with this bug.
> 

Actually I had seen this problem too, and this patched fixed it, or at least made the problem not come up.
(In reply to comment #72)
> (From update of attachment 205771 [details] [edit])
> Attachment #205771 [details] [edit] has nothing to do with this bug.
> 

Not sure how come u are so sure about this... That's the defacement I get right after the described bug/ui operations. I will be waiting for the update from mozilla (1.5.1) before commenting more on this.
Comment on attachment 204011 [details] [diff] [review]
patch

Please land on 1.8.0 and 1.8 branches.
Attachment #204011 - Flags: approval1.8.1+
Attachment #204011 - Flags: approval1.8.0.1?
Attachment #204011 - Flags: approval1.8.0.1+
Fix checked in to MOZILLA_1_8_BRANCH, 2005-12-20 17:34 -0800.
Fix checked in to MOZILLA_1_8_0_BRANCH, 2005-12-20 17:38 -0800.
Keywords: fixed1.8.0.1
*** Bug 321980 has been marked as a duplicate of this bug. ***
(In reply to comment #72)
> (From update of attachment 205771 [details] [edit])
> Attachment #205771 [details] [edit] has nothing to do with this bug.
> 

the bug got more and more annoying (cummulative?) so I had to get the nightly build. Just wanted to mention that build of 12.30.2005 solves this as well as the issue with my defaced UI (attachment #205771 [details])
could you point me to a link to that build?
also, is it a "firefox" build. the last nightly build someone pointed me to had a different name and crashed most of the time

(In reply to comment #79)
> (In reply to comment #72)
> > (From update of attachment 205771 [details] [edit] [edit])
> > Attachment #205771 [details] [edit] [edit] has nothing to do with this bug.
> > 
> 
> the bug got more and more annoying (cummulative?) so I had to get the nightly
> build. Just wanted to mention that build of 12.30.2005 solves this as well as
> the issue with my defaced UI (attachment #205771 [details] [edit])
> 

(In reply to comment #80)
> could you point me to a link to that build?
> also, is it a "firefox" build. the last nightly build someone pointed me to had
> a different name and crashed most of the time

latest nightly builds here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0/

the one I used is (I believe ->someone correct me if I'm wrong<-) here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-12-30-03-mozilla1.8.0/ (for mac)
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-12-30-04-mozilla1.8.0/ (for linux)
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-12-30-05-mozilla1.8.0/ (for windows)

good luck.

PS. you might have got the 1.6a1? crashed in my system as well. type about: to the address bar and you'll see a date like this: "Gecko/20051230 Firefox/1.5"
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
Status: RESOLVED → VERIFIED
Depends on: 393976
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.