User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
persistant problem, (only firefox 1.5 rc3 - beta, firefox 1.0 unaffected).
browser checks for updates, then defaults to the firefox branded google webpage. all systems opperational. however, when entering a search parameter the spinning disc of death appears and no further response can be had from the app.
Steps to Reproduce:
1. launch firefox 1.5 rc3
2. allow app to do normal checks and redirect to http://www.google.co.uk/firefox
3. start to enter search parameter
no response from app
spinning disc of death
allowed to complete the search field parameters, and therefore allow the website complete search.
no talkback data recorded.
Originally reportaed as : spinning disc of death when trying to enter details into google's website search text field
Over time i have discovered what i believe to be the same problem in other parts of firefox. The same symptomatic hang occurs when data is entered into a text field or an option is to be chosen from a list box, either as part of firefox's tool bar (i.e. the address bar or the search box) or in a web page.
The hang is severe and requires a forced termination of the application as the only cause of action. The hang does not occur every time, but is usually when data is generated in someway, i.e. if firefox tries to help by filling in a query or if a page generates a list dynamically, although this not exclusively the case and can occur without any dynamic generation.
This problem affects both versions 1.0 and 1.5, therefore assumed to be the same cause and considered a major issue. Please fix as is incredably irritating. there is often no way to recover whatever windows/pages wer open at the time of the crash as they are not necessarily the details in the "Go" menu. a crash detection system that lists the details of the windows/tabs that were open at the time of the crash would be a useful addition, though a fix would be better :-)
I have found that deleting the file formhistory.dat fixes the problem temporarily. However, this file is recreated with relaunching firefox, and eventually the problem begins happening again
I have the same problem...when I've been working on a site with forms, if Firefox attempts to help fill in a field, and drops down a menu of options, the program freezes, even if I don't click in the drop down. I have to force quit to end the program. This has happened repeatedly. I'm running ver 1.5 on a Mac OS X 10.2.8
*** This bug has been marked as a duplicate of 319747 ***
*** This bug has been marked as a duplicate of 294476 ***
Sorry for the bugspam, I can't keep my bugs straight. I think this is right.
*** This bug has been marked as a duplicate of 298502 ***
Ok, so first time since installing 184.108.40.206rc1 that it screwed-up again... so the bug is most defininitely still with us. Had approx 9 tabs open. filled in a search parameter into a textfield on a website. has done so 3 three times before hang occured, twice with the same entry, once (penultimate time) with a different entry, and finally with the last entry identical to the one before... reason for multiple same/similar requests was website was not finding the entry. only two entries in the dropdown field that appeared, but hang occured after display (no further response to any user interaction, only spinning disc.)
Additional Comment (for got to add this): on this occasion, firefox had only been running for about 30mins, only 2 other applications on the system were running (email and notes). the system had not become idle, nor had it gone to sleep, or had firefox been made to minimise, maximise, or anything else.
This bug (Bug 318283) has been reopened as although originally duped and though these bugs (Bug 319747) may be related, they are DEFINITLY not the same.
A quick update:
Ok, so with discs whiring away in the background, i can confirm that firefox still screws up in the same manor... beach balling on the auto-fill list dropdown. It has absolutley nothing to do with focus or minimization. Hence it is not Bug 294476 either, although this may be related. See notes on the bugs mentioned as they contain notes that are not included here, but are relavent to this bug (especially notes posted by myself and notes in direct response to them)
This bug has no crash reports or sampler traces, giving the developers nothing to go on. Please generate a sampler trace (this may require installing the developer tools on 10.2).
Does this bug only affect 10.2.8 users?
afraid not, though i know it affects ALL 10.2 (Jaguar) users, it would appear that is affects other users but i have no way to verify. The reason no crash report has been done is that firefox does not crash it hangs, hence not talkback/crash report is generated, one has to FORCE QUIT firefox and restart. The bug is also most intermitant making it hard to verify, as discussed in the notes of the previously duped bugs. hope this is of help.
please reread commment 10, or perhaps read it for the first time.
install sampler.app and use it. then attach your sample.
timeless: no need to be sarcastic. i have and will, but as yet there is no trace to report, this being a bit of an intermitant issue.
Why is this not a duplicate of bug 319747?
(In reply to comment #14)
> Why is this not a duplicate of bug 319747?
comment 1 states that it is an input issue where the carret or the mouse
cursor is not generating a response from a text field (or later on any other embedded component). This bug (Bug 318283) is specifically the drop-down auto fill that is causing the hang, it has no other attributes, all other signals are processed as expected up until the hang. Hence i say it may be relate, but not necessarily the same, and hence the bug being reopened, trying to avoid cross contaminating solutions to bugs.
(In reply to comment #6)
> Sorry for the bugspam, I can't keep my bugs straight. I think this is right.
> *** This bug has been marked as a duplicate of 298502 ***
It is probably related, but not the same. The bookmark hang is fixed with 220.127.116.11, but form autofill still hangs. Did I read somewhere that this is fixed on the trunk?
> Did I read somewhere that this is fixed on the trunk?
You have read it, as have i, but as yet i have no corroberation... all releases (that i have had access or privilide to use) have this same error. I know every one is working hard to solve this, but i'm not holding my breath just yet.
tried attaching sample, but sample data is 648kb, atachments must be less than 300kb according to submission page. sampler output doesnt mean a great deal to me, other than showing things like stack trace, etc. unsure how to break and attach - dont want to miss anything useful out.
(In reply to comment #18)
> tried attaching sample, but sample data is 648kb, atachments must be less than
> 300kb according to submission page. sampler output doesnt mean a great deal to
> me, other than showing things like stack trace, etc. unsure how to break and
> attach - dont want to miss anything useful out.
Stack trace is exactly what we want to see. Either zip the attachment and upload it, or put it up on a web site somewhere and post the url.
Created attachment 210759 [details]
Sampler output during data dentry hang
Unfortunately that sample has no symbol information.
After being able to get some symbosl for the stack trace, this doesn't look like a sample of a hung app to me. Darren: did you launch Firefox from Sampler and sample the entire run, or just Attach from Sampler after Fx hung? The latter would be more useful (and should give you a smaller sample file). So the procedure is this:
Run Firefox (please say which version), and do whatever it takes to get it to hang.
Launch Sampler, and Attach to firefox-bin.
Click Start Recording, and wait for 10 seconds.
Click Stop Recording, then save the trace.
I can confirm this on 10.2.8. It occurs when the autofill popup menu needs to shrink because the user entered more data and the list of selections should become more limited. I'm setting up a 10.2.8 system in an easily-VNCable location so I can fix and test. This looks like a case of bug 298502 that didn't get enough QA. Sorry, looks like 10.2 compat will need to wait until 18.104.22.168 - in the mean time, you can run with auto-fill turned off.
This is hanging in when SizeWindow is called by nsMacWindow::Resize(int,int,int,int) and we were already in an update (mInUpdate is true). Sampling teaches:
MoveResizeWindowInternal(WindowData*,short,short,short,unsigned char,unsigned char,unsigned char,unsigned char,Rect const*,unsigned long)
Similar to the issue in bug 289973. Evil resize-inside-update stuff again.
The update event handler from that patch is down below on the stack, but breaking out of BeginUpdate isn't helping us out here. There doesn't seem to be anything that can be done locally to avoid the hang, short of skipping the call to SizeWindow - can't do that. One hackaround might be to defer the resize until some time after the update - could be a 10.2 only hack, but I'd prefer to figure something better out if possible.
Created attachment 211046 [details] [diff] [review]
This defers the SizeWindow call until the update is done for real. It's only built if the target app is capable of running on 10.2 (so it's built for ppc by default but not x86) and only actually defers SizeWindow if running on a pre-10.3 host.
It's here, it works, and it's ugly, just like the other resize-inside-update hack that happens to work on 10.3 and up.
blocking 22.214.171.124 denied, not a regression, no trunk-baked patch.
Out of curiosity what has the size/resize got to do with the text field and dropdown hang? or am i mis-interpreting the last few comments, are they to do with the memory 'window' or the graphics 'window' rather than the actual UI window? i understand about the autofill list 'shrinking' as data is entered, but what seems to be the trigger?
(In reply to comment #29)
> Out of curiosity what has the size/resize got to do with the text field and
> dropdown hang? or am i mis-interpreting the last few comments, are they to do
> with the memory 'window' or the graphics 'window' rather than the actual UI
> window? i understand about the autofill list 'shrinking' as data is entered,
> but what seems to be the trigger?
The dropdown list is actually a separate little top-level window.
Darren, our pop-up menus are actually implemented as windows, with all of the title bars and resize boxes and other aqua goo stripped out. We create these "simple" windows and then draw what we need into them on our own. In this case, we're drawing the autocomplete menu into the window. They're real live windows as much as document windows or dialog boxes as far as the OS is concerned, and as far as Simon, Josh, and I are concerned, but that's just what's going on under the hood. As far as users are concerned, they're menus. Confusing? Sure, why not. But now you know a deep dark Mozilla truth.
What's happening here is that the system is calling us up and saying "hey, update Darren's window" (now that you've been initiated, you know that the window corresponds to the autocomplete popup menu) and we dutifully go to work. Before that update is done, we realize that we're losing a menu item, so the corresponding window needs to shrink. We tell the system to change the size of the window, and that's where the system gets confused. Resizing isn't something that's supposed to happen in the middle of an update. We're supposed to draw inside the window, not change its size. This general issue has caused other problems for us in the past.
The "hackaround" says that when running on 10.2, if something tries to resize a window (like your autocomplete menu) in the middle of an update, the resize will be postponed until it's safe, after the update has finished.
Comment on attachment 211046 [details] [diff] [review]
Kinda ugly that the hack is spread across two classes. If this goes onto the trunk, maybe try to contain the resize futzing in one file (via some virtual methods).
HandleUpdateEvent is already virtual, I can handle this entirely in nsMacWindow. I was actually planning on doing that anyway to better handle the aFromUI argument (which should always be false if there's an update going on anyway) and to avoid going through the max-size logic twice.
Just as soon as cvs comes back to me.
Created attachment 211105 [details] [diff] [review]
Moved all of the changes into nsMacWindow. I meant Update, not HandleUpdateEvent. There's an hour I won't be getting back.
I left mResizeTo = PR_FALSE in Update().
And I left out the word "out" in the previous comment.
I highly recommend that we take this for the 126.96.36.199. We're still not right on Mac OS X 10.2 with this problem around.
Fixed on the trunk and 1_8 branch.
Created attachment 211125 [details] [diff] [review]
As checked in
Regarding comment 28, this actually is a regression relative to 1.0 - also see comment 37.
Comment on attachment 211125 [details] [diff] [review]
As checked in
approved for 1.8.0 branch, a=dveditz for drivers
*** Bug 322431 has been marked as a duplicate of this bug. ***
Darren, can you please grab the latest build from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0 and let us know if the problem is fixed?
(In reply to comment #44)
> Darren, can you please grab the latest build from
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0 and
> let us know if the problem is fixed?
Just discovered this bug (I'd been aware of 298502 & 316423), grabbed that build, and eagerly turned Saved Forms back on. So far, so good. Admittedly it's been a brief test, but I've successfully done things that would've caused a hang before (and I hadn't cleared the form history, just turned it off, so there were plenty of options popping up and disappearing as I typed).
will do, downloaded, and under test. will post more inc trace if problem reappears.
*** Bug 316423 has been marked as a duplicate of this bug. ***
Seems fixed on the 1.8.0 branch. I'm still running the nightly from a week ago, and everything seems fine. Formfill dropdowns are back in business. Thanks for the great work.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:188.8.131.52) Gecko/20060220 Firefox/184.108.40.206
verified on the 220.127.116.11 branch using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:18.104.22.168) Gecko/20060306 Firefox/22.214.171.124. I tested on a Mac running 10.2.8 and did not experience any hangs. Adding keyword.
still working fine, appears to be fixed on 10.2.6
hey - i'm not much of a computer guy (it tooks me 3 days to find this site), but the dropdown autoform hangs me everytime (Mac 10.2.8).
Is it fixable?
(In reply to comment #51)
> Is it fixable?
It is fixed. The next release with this fix will be 126.96.36.199.
Thanks Gavin - I appreciate the update
> It is fixed. The next release with this fix will be 188.8.131.52.
*** Bug 331217 has been marked as a duplicate of this bug. ***
*** Bug 331362 has been marked as a duplicate of this bug. ***
*** Bug 332469 has been marked as a duplicate of this bug. ***
*** Bug 332813 has been marked as a duplicate of this bug. ***
*** Bug 333596 has been marked as a duplicate of this bug. ***
This doesn't seem to be fixed- E-Bay still crashes when you delete characters out too quickly- freezes up and crashes out
Catherine, what version of Firefox are you using? This will be fixed in 184.108.40.206, which isn't out yet.
I am using a Power Mac- iMac G3 with O S X operating software- never had problem with the older version of Firefox- only seems to be a problem with Firefox 1.5- the one available to download at the moment on Mozilla
*** Bug 330459 has been marked as a duplicate of this bug. ***