Last Comment Bug 305970 - Certain UI operations (opening dialogs, drag and drop) cause refresh, prolonged hang (CPU at 100%)
: Certain UI operations (opening dialogs, drag and drop) cause refresh, prolong...
Status: VERIFIED FIXED
[patch]
: fixed1.8.1, hang, regression, verified1.8.0.1
Product: Core Graveyard
Classification: Graveyard
Component: GFX: Gtk (show other bugs)
: Trunk
: x86 Linux
: P1 major with 9 votes (vote)
: mozilla1.9alpha1
Assigned To: David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch)
:
Mentors:
: 307260 309453 309499 313386 314112 315158 316247 316872 316983 317163 317929 318227 318948 319260 319261 319667 319873 320107 320109 321980 (view as bug list)
Depends on: 393976
Blocks: 238854 240276
  Show dependency treegraph
 
Reported: 2005-08-25 14:46 PDT by Dennis Jacobfeuerborn
Modified: 2009-01-22 10:17 PST (History)
43 users (show)
asa: blocking1.8b5-
dveditz: blocking1.8.1+
dveditz: blocking1.8.0.1+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
First Save Image misbehavior in THUNDERBIRD (149.96 KB, image/png)
2005-11-15 13:54 PST, David A. Cobb
no flags Details
First Save Image misbehavior in FIREFOX (144.80 KB, image/jpeg)
2005-11-15 14:01 PST, David A. Cobb
no flags Details
patch (6.82 KB, patch)
2005-11-22 19:31 PST, David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch)
caillon: review+
bryner: superreview+
mtschrep: approval1.8.0.1+
mtschrep: approval1.8.1+
Details | Diff | Splinter Review
Firefox slightly defaced due to bug - for documentation (159.92 KB, image/png)
2005-12-13 15:56 PST, towsonu2003
no flags Details

Description Dennis Jacobfeuerborn 2005-08-25 14:46:05 PDT
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.
Comment 1 Adam Guthrie 2005-08-25 18:57:09 PDT
Can you reproduce this in a clean profile? Also, what version of GTK are you
using? This sounds kind of similar to bug 304983.
Comment 2 Ria Klaassen (not reading all bugmail) 2005-08-26 01:57:07 PDT
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.
Comment 3 Dennis Jacobfeuerborn 2005-08-26 04:59:15 PDT
(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.
Comment 4 Dennis Jacobfeuerborn 2005-08-27 06:16:10 PDT
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.
Comment 5 Adam Guthrie 2005-08-28 11:25:05 PDT
Dennis, is this still an issue after updating gtk and cairo?
Comment 6 Dennis Jacobfeuerborn 2005-08-28 12:55:28 PDT
(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.
Comment 7 Dennis Jacobfeuerborn 2005-08-31 03:08:14 PDT
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).
Comment 8 Dennis Jacobfeuerborn 2005-08-31 03:14:03 PDT
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.
Comment 9 Dennis Jacobfeuerborn 2005-08-31 13:06:34 PDT
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.
Comment 10 Dennis Jacobfeuerborn 2005-09-06 13:10:17 PDT
I just noticed that the "scoll to the top" effect also occurs when I start
dragging the icon from the address bar.
Comment 11 Asa Dotzler [:asa] 2005-09-13 10:21:05 PDT
ROC, could this be related to any of your changes on the 28th?
http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=2005-04-28+05%3A00&maxdate=2005-04-29+08%3A00
Comment 12 Asa Dotzler [:asa] 2005-09-15 16:24:55 PDT
not going to block on this but if we get a low-risk fix, we'd consider it.
Comment 13 Dennis Jacobfeuerborn 2005-10-09 06:29:00 PDT
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.
Comment 14 Adam Guthrie 2005-10-09 13:19:00 PDT
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.
Comment 15 Dennis Jacobfeuerborn 2005-10-10 06:01:13 PDT
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.
Comment 16 Adam Guthrie 2005-10-10 14:07:20 PDT
I'll take your word for it, Dennis. Someone probably needs to figure out what
component this needs to go in.
Comment 17 Dennis Jacobfeuerborn 2005-10-11 10:04:01 PDT
I'll move it to Core/Layout since that's where bug 240276 lives and it's a
better match than Firefox/Menus.
Comment 18 Dennis Jacobfeuerborn 2005-10-13 09:40:29 PDT
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.
Comment 19 Kelson 2005-10-19 11:44:45 PDT
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
Comment 20 Tuukka Tolvanen (sp3000) 2005-10-21 13:45:29 PDT
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.
Comment 21 Tuukka Tolvanen (sp3000) 2005-10-22 05:33:17 PDT
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).
Comment 22 Tuukka Tolvanen (sp3000) 2005-10-22 06:13:17 PDT
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.
Comment 23 Andrea Iob 2005-10-26 02:56:12 PDT
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)
Comment 24 Adam Guthrie 2005-11-01 22:37:27 PST
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...
Comment 25 Dennis Jacobfeuerborn 2005-11-05 14:59:46 PST
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.
Comment 26 Ilya Konstantinov 2005-11-13 08:39:13 PST
*** Bug 316247 has been marked as a duplicate of this bug. ***
Comment 27 Peter Sääf 2005-11-14 09:26:56 PST
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)
Comment 28 David A. Cobb 2005-11-15 13:54:20 PST
Created attachment 203167 [details]
First Save Image misbehavior in THUNDERBIRD
Comment 29 David A. Cobb 2005-11-15 14:01:48 PST
Created attachment 203169 [details]
First Save Image misbehavior in FIREFOX

Image somewhat compromised to get below 300Kb (png=>jpeg conversion)
Comment 30 David A. Cobb 2005-11-15 14:07:13 PST
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.
Comment 31 Ilya Konstantinov 2005-11-15 14:57:11 PST
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.
Comment 32 Elmar Ludwig 2005-11-17 14:23:04 PST
*** Bug 316872 has been marked as a duplicate of this bug. ***
Comment 33 Greg Norris 2005-11-18 13:59:36 PST
*** Bug 316983 has been marked as a duplicate of this bug. ***
Comment 34 Elmar Ludwig 2005-11-18 15:20:07 PST
*** Bug 314112 has been marked as a duplicate of this bug. ***
Comment 35 Jeff Walden [:Waldo] (remove +bmo to email) 2005-11-19 16:06:47 PST
*** Bug 315158 has been marked as a duplicate of this bug. ***
Comment 36 Kevin Brosnan 2005-11-20 16:01:16 PST
*** Bug 317223 has been marked as a duplicate of this bug. ***
Comment 37 Adam Guthrie 2005-11-20 19:49:51 PST
*** Bug 317163 has been marked as a duplicate of this bug. ***
Comment 38 David Wrench 2005-11-21 03:24:10 PST
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.
Comment 39 Andreas Kotowicz 2005-11-21 06:52:36 PST
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.
Comment 40 Daniel Cater 2005-11-22 14:53:44 PST
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.
Comment 41 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2005-11-22 17:58:18 PST
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.
Comment 42 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2005-11-22 19:31:41 PST
Created attachment 204011 [details] [diff] [review]
patch

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?
Comment 43 Ginn Chen 2005-11-22 23:57:40 PST
Tested on JDS 3 and ubuntu 5.10, this patch won't break bug 238854.
Comment 44 Adam Guthrie 2005-11-23 15:24:10 PST
*** Bug 313386 has been marked as a duplicate of this bug. ***
Comment 45 Adam Guthrie 2005-11-23 15:25:13 PST
*** Bug 307260 has been marked as a duplicate of this bug. ***
Comment 46 Adam Guthrie 2005-11-23 15:32:33 PST
*** Bug 309453 has been marked as a duplicate of this bug. ***
Comment 47 Andrew Schultz 2005-11-23 19:45:20 PST
*** Bug 309499 has been marked as a duplicate of this bug. ***
Comment 48 Christopher Aillon (sabbatical, not receiving bugmail) 2005-11-24 08:11:56 PST
Comment on attachment 204011 [details] [diff] [review]
patch

r=caillon.  Thanks for tracking this down.
Comment 49 Vidar Haarr (not reading bugmail) 2005-11-24 08:17:05 PST
(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.
Comment 50 raptor 2005-11-26 10:56:37 PST
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.
Comment 51 Øyvind Stegard 2005-11-26 17:25:05 PST
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...
Comment 52 Øyvind Stegard 2005-11-26 17:31:08 PST
(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.
Comment 53 Kevin Brosnan 2005-11-27 08:48:41 PST
*** Bug 317929 has been marked as a duplicate of this bug. ***
Comment 54 Eric Butler 2005-11-28 09:36:29 PST
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.
Comment 55 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2005-11-28 10:55:53 PST
(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).
Comment 56 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2005-11-28 14:45:29 PST
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).
Comment 57 David Wrench 2005-11-29 04:26:49 PST
(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
Comment 58 Dennis Jacobfeuerborn 2005-11-29 12:21:19 PST
The fix works fine here. Thanks!
Comment 59 Karl Trygve Kalleberg 2005-11-29 12:44:18 PST
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?
Comment 60 Adam Guthrie 2005-12-03 22:09:42 PST
*** Bug 318948 has been marked as a duplicate of this bug. ***
Comment 61 Martin Meyer 2005-12-04 01:37:44 PST
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?
Comment 62 Adam Guthrie 2005-12-05 22:50:51 PST
*** Bug 319261 has been marked as a duplicate of this bug. ***
Comment 63 Adam Guthrie 2005-12-05 22:51:43 PST
*** Bug 319260 has been marked as a duplicate of this bug. ***
Comment 64 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-12-06 15:22:19 PST
Changing the theme forces a relayout of all pages. This can be very slow if you have large and/or complex pages loaded.
Comment 65 Adam Guthrie 2005-12-07 09:11:46 PST
*** Bug 318227 has been marked as a duplicate of this bug. ***
Comment 66 Adam Guthrie 2005-12-09 12:56:42 PST
*** Bug 319667 has been marked as a duplicate of this bug. ***
Comment 67 Mark Kane 2005-12-09 13:21:22 PST
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
Comment 68 Adam Guthrie 2005-12-11 12:42:54 PST
*** Bug 319873 has been marked as a duplicate of this bug. ***
Comment 69 towsonu2003 2005-12-11 15:51:59 PST
Do we know when the update that contains the fix will be released? I couldn't find the release plan for updates anywhere. thanks.
Comment 70 Elmar Ludwig 2005-12-13 06:15:11 PST
*** Bug 320109 has been marked as a duplicate of this bug. ***
Comment 71 towsonu2003 2005-12-13 15:56:37 PST
Created attachment 205771 [details]
Firefox slightly defaced due to bug - for documentation

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 72 Kevin Brosnan 2005-12-13 17:00:12 PST
Comment on attachment 205771 [details]
Firefox slightly defaced due to bug - for documentation

Attachment #205771 [details] has nothing to do with this bug.
Comment 73 Adam Guthrie 2005-12-13 21:55:18 PST
*** Bug 320107 has been marked as a duplicate of this bug. ***
Comment 74 Ka-Hing Cheung 2005-12-14 09:24:42 PST
(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.
Comment 75 towsonu2003 2005-12-15 14:59:50 PST
(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 76 Mike Schroepfer 2005-12-19 16:09:13 PST
Comment on attachment 204011 [details] [diff] [review]
patch

Please land on 1.8.0 and 1.8 branches.
Comment 77 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2005-12-20 17:54:54 PST
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.
Comment 78 Adam Guthrie 2005-12-31 16:54:43 PST
*** Bug 321980 has been marked as a duplicate of this bug. ***
Comment 79 towsonu2003 2005-12-31 17:47:14 PST
(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])
Comment 80 uri 2005-12-31 21:16:06 PST
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])
> 

Comment 81 towsonu2003 2006-01-01 15:47:17 PST
(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"

Note You need to log in before you can comment on or make changes to this bug.