Closed
Bug 232715
Opened 20 years ago
Closed 20 years ago
Serious problems with browser after disk sleep
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: waynegwoods, Assigned: jhpedemonte)
References
Details
(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: see comment 28 for details)
Attachments
(1 file)
2.76 KB,
patch
|
mikepinkerton
:
review+
sfraser_bugs
:
superreview+
asa
:
approval-aviary+
dveditz
:
approval1.7.5+
asa
:
approval1.8a4+
|
Details | Diff | Splinter Review |
User-Agent: Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040129 Firebird/0.8.0+ If either Seamonkey or Firebird are running when the hard disk is put to sleep, they have serious functionality problems when the disk wakes again: Previously open browser windows still function somewhat, although click-and-hold context menus (e.g. click and hold on a link, if you want to "Open Link in New Tab") are broken, and the navigation bar fails to update the URL navigating via a bookmark or other link (curiously, it still seems to update the site icon). Browser windows opened after the wake are entirely unresponsive to navigation, except via the home button. Quitting and restarting the browser fixes the problem (until next time the disk goes to sleep). Reproducible: Always Steps to Reproduce: 1. Go to Apple Menu -> System Preferences -> Energy Saver and set sleep for 1 minute inactivity (not crucial, but obviously makes diagnosis time faster!) 2. Open Firebird or Seamonkey and navigate to a page. Observe that clicking and holding on a link brings up the regular context menu. 3. Leave the browser window open on the screen, and leave computer inactive until it goes to sleep. After the monitor goes dark, wait approx. 1 more minute until you hear the hard disk spin down. 4. Wake the computer up again. 5. Go to the browser window and click and hold on a link. Observe that the context menu doesn't appear. Navigate to various bookmarks and observe that the URL bar isn't being updated. 6. Open a new window in the browser. Observe that neither bookmarks or manually typed URLs will produce any activity. Actual Results: Browser windows fail to function normally. Expected Results: Browser windows should continue to function normally. I'm running Mac OS X 10.2.8, with all the latest updates. Both browsers use only the default theme and have no extensions. Bug also occurs with a clean profile. The bug occurs as recently as 20040129 Firebird/0.8.0+, and at least as far back as 20031217 Mozilla 1.6b. I haven't tried any earlier builds.
Updated•20 years ago
|
Whiteboard: DUPEME
Comment 1•20 years ago
|
||
Partially confirmed in build 2004013005 on Mac OS 10.2.8 9 (old iBook 300 MHz laptop) After the laptop went into a light sleep (display off, HD off), click-and-hold doesn't show the context menu anymore, neighter does ctrl-click. But I'm not seeing the problems with the url-bar (update ok) or with the bookmarks (menus pop down), I could navigate just fine. Except for the context-menu, everything was fine. But manually putting the laptop to deep sleep (power button or apple-menu), doesn't show this effect. It might be related to bug 97640.
Reporter | ||
Comment 2•20 years ago
|
||
Thanks Jo. Just as a clarification.... the bookmarks menu works fine for me too. It's only context menus that don't. Also, bookmarks themselves, or addresses manually typed in to the URL bar, only fail to start navigation in new browser windows that are opened after the sleep/wake. Did you try that with a new window?
Comment 3•20 years ago
|
||
Yes, I After a light sleep (display & HD off), I opened a new window (with cmd-N or with the menubar). In that new window the click-and-hold menu didn't work, but other events (clicking links, typing in fields, clicking backward/forward, ...) worked ok. And when I went to the locationbar (cmd-L, or click in the bar), I could type in a new URL, but the Enter key didn't seem to work. The same thing with choosing a bookmark. I also noticed that the preference dialog box doesn't want to close anymore (I wanted to add a go button, to see if that worked). Note that I wrote before the the ctrl-click didn't produce the context menu anymore. i have to retract that, b/c I can't reproduce that anymore (ctrl-click works). The workaround seems to be very simple : just put your system in deep-sleep (power-button or apple-menu), and everything will be restored. Even the preference dialog that was stuck, was gone ! I haven't found any duplicates though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 4•20 years ago
|
||
I have some more info on the origins of this bug. I tested it out on old Firebird builds. The last Firebird trunk build that DIDN'T have this problem was 20031030. The first build to show the bug was 20031103 (this build had broken menus and scrollbars as well... see bug 224526). In between was a gap of a few days where Mac builds weren't loading at all, so it's impossible to tell exactly when the bug was inserted. Kinda looks like a major bug was created before the October 31 build, and either it wasn't 100% fixed, or the fix introduced this problem. I have also reproduced this bug on a different machine (iMac) running OS X 10.3.2, so it's not just Jaguar. The symptoms observed on that machine were identical to that seen on my home machine. I have a feeling that sleep is handled differently on laptops, which could explain why the symptoms reported by Jo aren't identical to mine. Just guessing.
Comment 5•20 years ago
|
||
Then it might be a regression of bug 197863. I wonder if it can be reproduced in Camino as well (I might try it later tonight). CC'ing sfraser
Comment 6•20 years ago
|
||
*** Bug 234667 has been marked as a duplicate of this bug. ***
With Panther, on a 900MHz iBook... Moz 1.7b shows 'spinning wheel of death' after waking from sleep. Unsure of whether it's the same bug literally. - Firefox 0.8 recovers from sleep gracefully - Moz 1.6 recovers from sleep gracefully
Flags: blocking1.7+
only drivers should set blocking flags to + or -.
Flags: blocking1.7+ → blocking1.7?
Reporter | ||
Comment 9•20 years ago
|
||
*** Bug 235991 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 10•20 years ago
|
||
In the above duplicate, Dustin discovered that the bug also kills some javascript processes (see the timer in his example page in that bug). However it doesn't seem to kill all javascript, as pages with javascript menus that I tested still worked. Couple of other things of note: - I can only reproduce the sleep bug when my computer is connected to the internet (I use dial-up). - Selecting Sleep from the Apple menu won't cause the bug.
Comment 11•20 years ago
|
||
I've got the same problems using a 800 Mhz Titanium PowerBook under 10.3.3. when I close my PBs lid. Navigator windows are still working after waking up the machine, but get the spinning wheel and "program not responding" in the Dock when I push the "get new messages" button in Mozilla Mail.
Reporter | ||
Updated•20 years ago
|
Severity: major → critical
Reporter | ||
Comment 12•20 years ago
|
||
I notice that this bug doesn't seem to have an assignee yet. As Jo pointed out, this really does sound like a regression caused by bug 197863. While it might be a pure coincidence, the other bug also dealt with sleep and the fix was checked at the same time that this bug began. So perhaps this bug should be assigned to Simon Fraser as well? Sorry if I'm appearing impatient. Perhaps stuff is going on behind the scenes. :) I just noticed that this bug didn't have an assignee yet, and with 1.7 looming I was worried it'd been forgotten and wouldn't be fixed in time. For me, it's currently the most infuriating Mozilla bug that I encounter, on either Windows or Mac.
Comment 13•20 years ago
|
||
I'll ditto Wayne. I've had to switch to safari since this bug started showing up... I'm eager to get back to firefox. This bug should be marked as blocking 1.7 imho.
Comment 14•20 years ago
|
||
I wonder if this relates to bug 227680.
Reporter | ||
Comment 15•20 years ago
|
||
The dates and nature of the two bugs certainly suggest that they're linked. This further supports the likelihood of the fix for bug 197863 being the culprit. Can the fix for bug 227680 be modified to apply here? I know it involved Cocoa, but perhaps the underlying code changes are still the same.
Comment 16•20 years ago
|
||
pink, can you look at this and see if the changes at bug 197863 are responsible and if the fix at bug 227680 could be made to work for SeaMonkey?
Comment 17•20 years ago
|
||
This bug seems particularly vexing for iBook and Powerbook users, since these tend to sleep a lot.
Updated•20 years ago
|
Flags: blocking1.7? → blocking1.7+
Comment 18•20 years ago
|
||
*** Bug 242117 has been marked as a duplicate of this bug. ***
Comment 19•20 years ago
|
||
I tested this on my own iBook G4 800 / OSX.3.3 and Mozilla 1.7RC1 recovers from sleep without problems. Short flash of the spinning wheel, but only for a second or two (presumably waiting for virtual memory to be returned to solid state RAM).. I only tested the browser component, though.
Comment 20•20 years ago
|
||
I upgraded my iBook from Mozilla 1.6 (final) to 1.7 RC1, and now it hangs (spinning wheel of death for minutes) very frequently (6x). I use the browser and mail components. I suspect most of my crashes have to do with a change in network connectivity, e.g. from one 802.11b WiFi station to another; I recall once Mozilla had hung, I put it to sleep, and woke it on the WiFi it had been on, and it became responsive again. Until I can find something reproducible (I'm trying!), I'm not gonna open a new bug, just throwing out more "it may be mail or network-related" thoughts for confirmation/contradiction. (My hangs are post-1.6, unlike this bug's.) Mac Mozilla doesn't seem to come with the crash reporter, or at least the times it's actually crashed (not hung) all I've seen is Apple's crash reporter. Is there something I should install?
Reporter | ||
Comment 21•20 years ago
|
||
Some of the problems being described here for Powerbooks ('spinning wheel of death') are vastly different to the original condition described for desktop systems. That doesn't mean they're not resulting from the same bug, but it would be best to confirm that. If they're not, a new bug should be filed. Could some of you guys who've reported Powerbook problems under this bug please check the following: Please download Firefox builds 20031030 and 20031103. You can get these builds from: http://archive.mozilla.org/pub/firebird/nightly/ Please confirm that your bug occurs in the latter build, but not the former, and which symptoms you see (either the browser hanging/freezing/spinning wheel of death or a simple break down in functionality, like reported for desktop machines). thanks!
Assignee | ||
Comment 22•20 years ago
|
||
I just tried a Firefox nightly (20040506) on my desktop machine and saw no problems. I've also been using Firefox 0.8 and nightlies on my Powerbook, frequently sleeping with Firefox running. Haven't noticed any issues there, either. This is with OS X 10.3.3.
Comment 23•20 years ago
|
||
I haven't seen this bug in a while, either. I'm running a pretty old versin of Firefox so I'm guessing that a recent mac patch fixed this problem.
Reporter | ||
Comment 24•20 years ago
|
||
Maybe in Panther it did, but it's still broken in Jaguar, 10.2.8, all the latest updates, using 20040509 Firefox/0.8.0+ default theme, fresh profile. Just to check, you do have the "put hard disk to sleep" box checked in the energy saver, and you do wait till you hear it go to sleep before waking the computer up? Either way, I'm afraid the bug still exists.
Updated•20 years ago
|
Flags: blocking1.7+ → blocking1.7-
Comment 25•20 years ago
|
||
Still an issue with 1.7 RC3.
Comment 26•20 years ago
|
||
Still present in Firefox 0.9 and Mozilla 1.8a2, both on Mac OS X 10.2.8 (Jaguar) Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040621 At this moment, after a light sleep, behaviour is very erratic : - click-and-hold contextmenus don't work in either browser - but ctrl-click contextmenus works though - The urlbar-popdown works in Mozilla, but doesn't in Firefox. But then again, the search-popdown works in Firefox, so it's not in every popdown. - the about dialogbox doens't want to close in Firefox anymore. It works in Mozilla, but there it's a window.
Flags: blocking1.8a2-
Assignee | ||
Comment 27•20 years ago
|
||
OK, it looks like I can recreate this on my desktop machine, but not my laptop. I had a debug build running overnight, and when I woke it up this morning, it was showing this problem. I saw the following line in the console: WARNING: Dropping timer event because thread is dead, file /Users/pedemonte/builds/fox10/mozilla/xpcom/threads/nsTimerImpl.cpp, line 498 Not sure yet if it is related.
Comment 28•20 years ago
|
||
Partially confirmed with Panther 10.3.4 and Seamonkey 1.7 final on an iBook 900MHz After sleep - window-modal dialogs don't register clicks - if you end up with a locked window, force-quit is the only option - url autocompletion on location bar doesn't work - some page navigation shortcuts (space bar for example) don't work - throbber is static even when loading a url Versions - Seamonkey 1.8a shows the problem as well. AFAICT, this has been present since around 1.6, but there were other more serious problems with IMAP and waking from sleep too. Make sure you are not being affected by Mail and News bugs on wakeup, too. - Firefox 0.7 & 0.8 show the same problem. Firefox 0.9 reduces the problem somewhat: the throbber is still active and quit will handle gracefully windows locked with window-modal dialogs. Is there any fix on the nightlies that we should be trying?
Reporter | ||
Comment 29•20 years ago
|
||
No, as far as I know, nobody has fixed anything to do with this bug yet. Asa asked Mike Pinkerton to look at it in comment 16 (back in April), so it's likely on his list.
Assignee | ||
Comment 30•20 years ago
|
||
I backed out bug 197863 from my Firefox tree and when I woke up my machine this morning, it did not show the problems I had seen previously. So there is something in the patch from bug 197863 that needs tweeking. The only other interesting thing I've seen is the warning from comment #27.
Comment 31•20 years ago
|
||
Do the IOKit callbacks get called for disk sleep? Maybe we're turning off timers on disk sleep, as well as machine sleep.
Comment 32•20 years ago
|
||
just odd that camino doesn't have any issues but ff/tbird do.
Comment 33•20 years ago
|
||
Maybe becuase Camino isn't relying on Carbon Event-based PLevents?
Comment 34•20 years ago
|
||
I see this problem intermittently, which leads me to think it needs an extra factor to be reproduced 100%. So far, it seems to be a network mount (SMB or NFS). The network mount is not dropped, but mozilla (1.7) and firefox (0.9.x) will misbehave as described. If there is no network mount, moz and firefox are unaffected.
Reporter | ||
Comment 35•20 years ago
|
||
What exactly is a network mount? (and SMB or NFS?) :) We established earlier that you have to be connected to a network (or perhaps specifically dialled in, but not sure). While dialled in, I can reproduce this every time.
Assignee | ||
Comment 36•20 years ago
|
||
Well, it sounds crazy, but Martin seems to be right. My computer is always connected to the internet, but I only see this problem with firefox when I have an SMB volume mounted.
Comment 37•20 years ago
|
||
FWIW, I've seen this bug and to the best of my knowledge, there's never been an SMB mount on my system.
Reporter | ||
Comment 38•20 years ago
|
||
I wish I knew what an SMB mount was so I could check if I have one ;) All I have is a simple G4 desktop (HFS+) and I connect to the internet through dial-up using the standard Mac software and hardware. Sometimes I have CDs mounted, and sometimes not, but regardless, I can reproduce this problem every time if I'm dialled in.
Updated•20 years ago
|
Flags: blocking-aviary1.0mac?
Whiteboard: DUPEME → see comment 28 for details
Comment 39•20 years ago
|
||
*** Bug 249275 has been marked as a duplicate of this bug. ***
Comment 40•20 years ago
|
||
*** Bug 227528 has been marked as a duplicate of this bug. ***
Comment 41•20 years ago
|
||
I just posted this in response to a question posed on the duplicate issue 227528 and thought I should post here as well. I have this happen to me several times per day. I'm running 10.3.5 and I am up to date with all patches/updates - just did the G5 firmware patch this morning. I have installed the Apple X11 for testing the OpenOffice X11 install. I also have several SaMBa mounts which are automounted at boot time. Unfortunately, I use them all the time so I can't really remove them and still get my work done so i can't test if that is it. This issue is by far the most critical issue for me. I have recently moved the Safari browser icon to my Dock simply because of this issue - even though I much prefer using Firefox.
Comment 42•20 years ago
|
||
*** Bug 259161 has been marked as a duplicate of this bug. ***
Comment 43•20 years ago
|
||
*** Bug 259913 has been marked as a duplicate of this bug. ***
Comment 44•20 years ago
|
||
I can not get this problem to appear on the new Firefox 1.0 Preview Release and I did see it before. Fixed? Can anyone else confirm?
Comment 45•20 years ago
|
||
I'm using PR1.0 and it still happens to me quite consistently - 3 or 4 times per day.
Comment 46•20 years ago
|
||
rats!
Comment 47•20 years ago
|
||
I've seen this bug without even needing a sleep. It's happened to me within as little as, say, 30 seconds of opening the browser. This is on iBook G4 800MHz, 10.3.4 and 10.3.5. You'll see my findings on this in bug #257819.
Comment 48•20 years ago
|
||
Just to clarify on my previous post, I'm seeing the issue and I have *no* NFS, SAMBA or any other network mounts, or even additional mounted volumes such as CDs. I've seen the issue while connected to a network with a static IP, with a DHCP IP, and also with the network connection being down (e.g. when I'm on the train.)
Comment 49•20 years ago
|
||
(In reply to comment #45) > I'm using PR1.0 and it still happens to me quite consistently - 3 or 4 times per > day. Me too. I would say it's blocking 1.0 on the mac. When will this be fixed??? Are anyone working to fix it?
Comment 50•20 years ago
|
||
(In reply to comment #45) > I'm using PR1.0 and it still happens to me quite consistently - 3 or 4 times per > day. Me too. I would say it's blocking 1.0 on the mac.
Reporter | ||
Comment 51•20 years ago
|
||
I think everyone already realizes what a critical issue this is. However, I don't think anyone can work out what the cause of this bug is, other than that it was induced by the fix for bug 197863 by Mike Pinkerton, Simon Fraser, etc. There was a patch in another bug report that fixed a similar problem in Camino (attachment 139313 [details] [diff] [review] of bug 227680). That patch made changes to /mozilla/widget/src/mac/nsToolkitBase.cpp and /mozilla/widget/src/mac/nsToolkitBase.h . Judging from the directory path, however, I'm guessing that the changed code is already part of Firefox and Seamonkey, and therefore won't fix our problem. I could be wrong, though.
Comment 52•20 years ago
|
||
*** Bug 233846 has been marked as a duplicate of this bug. ***
Comment 53•20 years ago
|
||
Is there anything that we as users can do to help track down what the issue is? Is there a way to turn on debug logging or is there an easy way to get an installation of a debug build?
Assignee | ||
Comment 54•20 years ago
|
||
So this is what is going on: 1) In the case where user actively selects 'Sleep', the callback function ToolkitSleepWakeCallback() receives a 'kIOMessageSystemWillSleep' message, and it posts a 'sleep_notification' notification. That works fine. 2) In the case where the system goes to sleep after a certain time, ToolkitSleepWakeCallback() first receives the 'kIOMessageCanSystemSleep' message, asking Mozilla if it is OK to go to sleep. Here, it sends a 'sleep_notification' notification, and responds OK. If the system is actually going to sleep, it then sends a 'kIOMessageSystemWillSleep' message, to which we send 'sleep_notification' again. I don't know if sending this twice in a row is bad. However, if we have responded that the system may go to sleep when receiving 'kIOMessageCanSystemSleep', and then another app cancels the sleep, then we are in a wierd state where Mozilla has put threads/timers to sleep even though the system is still running. This patch makes it so we allow the system to go to sleep if we get 'kIOMessageCanSystemSleep', but don't send out a 'sleep_notification'. We only do that when we get the 'kIOMessageSystemWillSleep' message.
Assignee: general → jhpedemonte
Status: NEW → ASSIGNED
Assignee | ||
Updated•20 years ago
|
Attachment #159620 -
Flags: superreview?(sfraser)
Attachment #159620 -
Flags: review?(peterv)
Assignee | ||
Comment 55•20 years ago
|
||
Oh, and the reason some of us were seeing this with an SMB mount was that the SMB mount cancels the system sleep (at least for a while).
Comment 56•20 years ago
|
||
Comment on attachment 159620 [details] [diff] [review] patch Nice job.
Attachment #159620 -
Flags: superreview?(sfraser) → superreview+
Comment 57•20 years ago
|
||
Comment on attachment 159620 [details] [diff] [review] patch awesome catch, i could never repro so tracking it down seemed unlikely. r=pink
Attachment #159620 -
Flags: review?(peterv) → review+
Assignee | ||
Comment 58•20 years ago
|
||
Comment on attachment 159620 [details] [diff] [review] patch Asking for approval across the board. This is a pretty serious bug for some people, forcing them to restart the browser and potentially lose data.
Attachment #159620 -
Flags: approval1.8a4?
Attachment #159620 -
Flags: approval1.7.x?
Attachment #159620 -
Flags: approval-aviary?
Updated•20 years ago
|
Flags: blocking-aviary1.0mac?
Comment 59•20 years ago
|
||
Comment on attachment 159620 [details] [diff] [review] patch a=asa for checkin to 1.8a4. Time is short for a4, so please land there quickly. Thanks.
Attachment #159620 -
Flags: approval1.8a4? → approval1.8a4+
Assignee | ||
Comment 60•20 years ago
|
||
Checked into trunk.
Comment 61•20 years ago
|
||
*** Bug 250294 has been marked as a duplicate of this bug. ***
Comment 62•20 years ago
|
||
Comment on attachment 159620 [details] [diff] [review] patch a=dveditz for 1.7 branch. Please add the fixed1.7.x keyword after checkin
Attachment #159620 -
Flags: approval1.7.x? → approval1.7.x+
Updated•20 years ago
|
Whiteboard: see comment 28 for details → [fixed on trunk] see comment 28 for details
Assignee | ||
Updated•20 years ago
|
Keywords: fixed1.7.x
Comment 63•20 years ago
|
||
I don't know if this is the wrong place to ask, since this maybe is a more general question,? but how long will it take before this patch makes it into firefox? and when will it make it from the nightly ff builds to the preview?
Reporter | ||
Comment 64•20 years ago
|
||
Confirmed fixed in the lastest nightly trunk build (20040923). I can't believe it's finally over. ;) Javier, you are a God! I'm on a G4 desktop machine running 10.2.8. Hopefully some of our laptop users can confirm it's fixed for them as well, since some of their symptoms were a bit different.
Comment 65•20 years ago
|
||
Comment on attachment 159620 [details] [diff] [review] patch a=asa for aviary checkin.
Attachment #159620 -
Flags: approval-aviary? → approval-aviary+
Assignee | ||
Updated•20 years ago
|
Comment 66•20 years ago
|
||
Will this fix aboutmagically make it into Thunderbird (which right now has the same problem) too? Or how does the code base work?
Assignee | ||
Comment 67•20 years ago
|
||
Emil, yes this will make it into all the Gecko based apps.
Comment 68•20 years ago
|
||
*** Bug 260993 has been marked as a duplicate of this bug. ***
Comment 69•20 years ago
|
||
Hi. Is there any way I can use bugzilla to determine if this was included in the latest build (0.10.1)? pete. ps. Thanks Javier on an excellent bit of detective work.
Comment 70•20 years ago
|
||
> Is there any way I can use bugzilla to determine if this was included in the
> latest build (0.10.1)?
>
> pete.
I'm still experiencing this bug in Firefox 0.10.1 using Mac OS 10.3.5, fully
updated, on a Powerbook G4 Aluminum. The fix sounds right to me so I'm guessing
it has not made it into Firefox yet.
This is one of the most annoying browser problems I've ever encountered so I am
VERY glad to see help on the way.
Is there a patch we can apply without waiting for a new release? I can't find
nightly builds of the Firefox 0.10 pre-release on the Mozilla site - must be
there somewhere - maybe somebody can clue us in.
Comment 71•20 years ago
|
||
Pete, just use this one: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/mozilla-mac-MachO.dmg.gz Cheers
Reporter | ||
Comment 72•20 years ago
|
||
Does that mean this bug isn't fixed on the Aviary branch yet? It has the keywords "fixed-aviary1.0, fixed1.7.x", and it's resolved as fixed. If not, we should reopen it.
Assignee | ||
Comment 73•20 years ago
|
||
This was not included in Firefox 0.10.1 (that was just a security fix), but it will be in the next official version. In the meantime, you can use one of the Firefox nightlies (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/Firefox-mac.dmg.gz)
Comment 74•20 years ago
|
||
I'm on a Powerbook G4 Aluminum running 10.3.5. Downloaded the 10/11 Firefox nightly build at 10 AM today and have used it all day, through several sleep cycles, without experiencing either the sheet freeze problem or the click-and-hold context menu problem. Confirming bug fixed on my laptop. Javier, you are magnificent!
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
Whiteboard: [fixed on trunk] see comment 28 for details → see comment 28 for details
Comment 75•20 years ago
|
||
*** Bug 263955 has been marked as a duplicate of this bug. ***
Comment 76•20 years ago
|
||
*** Bug 265562 has been marked as a duplicate of this bug. ***
Comment 77•20 years ago
|
||
*** Bug 238574 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 78•20 years ago
|
||
*** Bug 275763 has been marked as a duplicate of this bug. ***
Comment 79•20 years ago
|
||
*** Bug 275747 has been marked as a duplicate of this bug. ***
Comment 80•20 years ago
|
||
I have been working with v1 for the past week or so and have had absolutely no problems. Thank you everyone for fixing this bug and the great work. I feel like I have gotten more than monies worth in donating to Mozilla/Firefox! cheers dn
Comment 81•19 years ago
|
||
*** Bug 268325 has been marked as a duplicate of this bug. ***
Comment 82•18 years ago
|
||
304298 and 325188 would tend to suggest that this bug isnt fixed entirely.
You need to log in
before you can comment on or make changes to this bug.
Description
•