Closed
Bug 305970
Opened 18 years ago
Closed 18 years ago
Certain UI operations (opening dialogs, drag and drop) cause refresh, prolonged hang (CPU at 100%)
Categories
(Core Graveyard :: GFX: Gtk, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: dennisml, Assigned: dbaron)
References
Details
(4 keywords, Whiteboard: [patch])
Attachments
(3 files, 1 obsolete file)
149.96 KB,
image/png
|
Details | |
144.80 KB,
image/jpeg
|
Details | |
6.82 KB,
patch
|
caillon
:
review+
bryner
:
superreview+
mtschrep
:
approval1.8.0.1+
mtschrep
:
approval1.8.1+
|
Details | Diff | Splinter Review |
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•18 years ago
|
||
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•18 years ago
|
||
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.
Reporter | ||
Comment 3•18 years ago
|
||
(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.
Reporter | ||
Comment 4•18 years ago
|
||
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•18 years ago
|
||
Dennis, is this still an issue after updating gtk and cairo?
Reporter | ||
Comment 6•18 years ago
|
||
(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.
Reporter | ||
Comment 7•18 years ago
|
||
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).
Reporter | ||
Comment 8•18 years ago
|
||
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.
Reporter | ||
Comment 9•18 years ago
|
||
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.
Reporter | ||
Comment 10•18 years ago
|
||
I just noticed that the "scoll to the top" effect also occurs when I start dragging the icon from the address bar.
Reporter | ||
Updated•18 years ago
|
Flags: blocking1.8b5?
Comment 11•18 years ago
|
||
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•18 years ago
|
||
not going to block on this but if we get a low-risk fix, we'd consider it.
Flags: blocking1.8b5? → blocking1.8b5-
Reporter | ||
Comment 13•18 years ago
|
||
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•18 years ago
|
||
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
Reporter | ||
Comment 15•18 years ago
|
||
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•18 years ago
|
||
I'll take your word for it, Dennis. Someone probably needs to figure out what component this needs to go in.
Reporter | ||
Comment 17•18 years ago
|
||
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
Reporter | ||
Comment 18•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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
Comment 21•18 years ago
|
||
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
Comment 22•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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
Reporter | ||
Comment 25•18 years ago
|
||
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•18 years ago
|
||
*** Bug 316247 has been marked as a duplicate of this bug. ***
Comment 27•18 years ago
|
||
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)
Updated•18 years ago
|
Flags: blocking1.8.1?
Comment 28•18 years ago
|
||
Comment 29•18 years ago
|
||
Image somewhat compromised to get below 300Kb (png=>jpeg conversion)
Comment 30•18 years ago
|
||
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•18 years ago
|
||
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
Comment 32•18 years ago
|
||
*** Bug 316872 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
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%)
Comment 33•18 years ago
|
||
*** Bug 316983 has been marked as a duplicate of this bug. ***
Comment 34•18 years ago
|
||
*** Bug 314112 has been marked as a duplicate of this bug. ***
Comment 35•18 years ago
|
||
*** Bug 315158 has been marked as a duplicate of this bug. ***
Comment 36•18 years ago
|
||
*** Bug 317223 has been marked as a duplicate of this bug. ***
Comment 37•18 years ago
|
||
*** Bug 317163 has been marked as a duplicate of this bug. ***
Comment 38•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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.
Assignee | ||
Comment 41•18 years ago
|
||
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.
Assignee | ||
Comment 42•18 years ago
|
||
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)
Assignee | ||
Updated•18 years ago
|
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.9alpha
Comment 43•18 years ago
|
||
Tested on JDS 3 and ubuntu 5.10, this patch won't break bug 238854.
Comment 44•18 years ago
|
||
*** Bug 313386 has been marked as a duplicate of this bug. ***
Comment 45•18 years ago
|
||
*** Bug 307260 has been marked as a duplicate of this bug. ***
Comment 46•18 years ago
|
||
*** Bug 309453 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•18 years ago
|
Component: Layout → GFX: Gtk
Comment 47•18 years ago
|
||
*** Bug 309499 has been marked as a duplicate of this bug. ***
Comment 48•18 years ago
|
||
Comment on attachment 204011 [details] [diff] [review] patch r=caillon. Thanks for tracking this down.
Attachment #204011 -
Flags: review?(caillon) → review+
Comment 49•18 years ago
|
||
(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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
(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•18 years ago
|
||
*** Bug 317929 has been marked as a duplicate of this bug. ***
Comment 54•18 years ago
|
||
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.
Assignee | ||
Comment 55•18 years ago
|
||
(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).
Updated•18 years ago
|
Attachment #204011 -
Flags: superreview?(bryner) → superreview+
Assignee | ||
Comment 56•18 years ago
|
||
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: 18 years ago
Resolution: --- → FIXED
Comment 57•18 years ago
|
||
(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
Reporter | ||
Comment 58•18 years ago
|
||
The fix works fine here. Thanks!
Comment 59•18 years ago
|
||
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?
![]() |
||
Updated•18 years ago
|
Flags: blocking1.8.0.1?
Comment 60•18 years ago
|
||
*** Bug 318948 has been marked as a duplicate of this bug. ***
Comment 61•18 years ago
|
||
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•18 years ago
|
||
*** Bug 319261 has been marked as a duplicate of this bug. ***
Comment 63•18 years ago
|
||
*** 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.
Comment 65•18 years ago
|
||
*** Bug 318227 has been marked as a duplicate of this bug. ***
Comment 66•18 years ago
|
||
*** Bug 319667 has been marked as a duplicate of this bug. ***
Comment 67•18 years ago
|
||
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•18 years ago
|
||
*** Bug 319873 has been marked as a duplicate of this bug. ***
Comment 69•18 years ago
|
||
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•18 years ago
|
||
*** Bug 320109 has been marked as a duplicate of this bug. ***
Comment 71•18 years ago
|
||
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•18 years ago
|
||
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
Assignee | ||
Updated•18 years ago
|
Attachment #204011 -
Flags: approval1.8.0.1?
Comment 73•18 years ago
|
||
*** Bug 320107 has been marked as a duplicate of this bug. ***
Comment 74•18 years ago
|
||
(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•18 years ago
|
||
(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•18 years ago
|
||
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+
Assignee | ||
Comment 77•18 years ago
|
||
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
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.1
Comment 78•18 years ago
|
||
*** Bug 321980 has been marked as a duplicate of this bug. ***
Comment 79•18 years ago
|
||
(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•18 years ago
|
||
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•18 years ago
|
||
(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"
Updated•18 years ago
|
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
Updated•15 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•