318283 - [10.2] Hangs on data entry when autofill popup menu should shrink

Status: RESOLVED FIXED

(Toolkit :: Form Manager, defect)

Description

[Darren Robinson]

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.

Reproducible: Always

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

Actual Results:  
no response from app
spinning disc of death

Expected Results:  
allowed to complete the search field parameters, and therefore allow the website complete search.

no talkback data recorded.

Comment 1

[Darren Robinson]

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 :-)

Comment 2

[Adam Farber]

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

Comment 3

[Matthew Alschuler]

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

Comment 4

[:Gavin Sharp [email: [e-mail]]]

*** This bug has been marked as a duplicate of 319747 ***

Comment 5

[Mark Mentovai]

*** This bug has been marked as a duplicate of 294476 ***

Comment 6

[Mark Mentovai]

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 ***

Comment 7

[Darren Robinson]

Ok, so first time since installing 1.5.0.1rc1 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.)

Comment 8

[Darren Robinson]

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.

Comment 9

[Darren Robinson]

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)

Comment 10

[Simon Fraser [no longer active]]

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?

Comment 11

[Darren Robinson]

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.

Comment 12

[timeless]

please reread commment 10, or perhaps read it for the first time.

install sampler.app and use it. then attach your sample.

Comment 13

[Darren Robinson]

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.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

Why is this not a duplicate of bug 319747?

Comment 15

[Darren Robinson]

(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.

Comment 16

[Marc Rost]

(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 1.5.0.1, but form autofill still hangs.  Did I read somewhere that this is fixed on the trunk?

Comment 17

[Darren Robinson]

> 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.

Comment 18

[Darren Robinson]

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.

Comment 19

[Simon Fraser [no longer active]]

(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.

Comment 20

[Darren Robinson]

Attachment: Sampler output during data dentry hang

Comment 21

[Simon Fraser [no longer active]]

Unfortunately that sample has no symbol information.

Comment 22

[Simon Fraser [no longer active]]

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.

Comment 23

[Mark Mentovai]

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 1.5.0.2 - in the mean time, you can run with auto-fill turned off.

Comment 24

[Mark Mentovai]

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:

semaphore_wait_signal_trap
semaphore_wait_signal_trap
_pthread_cond_wait
CGSRWLockLockForWriting
_CGSLockForBufferChanges
CGSetWindowShapeWithWeighting
SetPlatformWindowShape
ResetPlatformWindowShape
CalculateWindowRegions(WindowData*)
WindowData::MoveResizeRgns(short,short,short,short,bool)
MoveResizeWindowInternal(WindowData*,short,short,short,unsigned char,unsigned char,unsigned char,unsigned char,Rect const*,unsigned long)
SizeWindow
nsMacWindow::Resize(int,int,int,int)

Comment 25

[Simon Fraser [no longer active]]

Similar to the issue in bug 289973. Evil resize-inside-update stuff again.

Comment 26

[Mark Mentovai]

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.

Comment 27

[Mark Mentovai]

Attachment: Hackaround

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.

Comment 28

[Daniel Veditz [:dveditz]]

blocking 1.8.0.2 denied, not a regression, no trunk-baked patch.

Comment 29

[Darren Robinson]

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?

Comment 30

[Simon Fraser [no longer active]]

(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.

Comment 31

[Mark Mentovai]

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 32

[Simon Fraser [no longer active]]

Comment on attachment 211046 [details] [diff] [review]
Hackaround

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).

Comment 33

[Mark Mentovai]

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.

Comment 34

[Mark Mentovai]

Attachment: Hackaround v2

Moved all of the changes into nsMacWindow.  I meant Update, not HandleUpdateEvent.  There's an hour I won't be getting back.

Comment 35

[Mark Mentovai]

I left mResizeTo = PR_FALSE in Update().

Comment 36

[Mark Mentovai]

And I left out the word "out" in the previous comment.

Comment 37

[Josh Aas]

I highly recommend that we take this for the 1.8.0.2. We're still not right on Mac OS X 10.2 with this problem around.

Comment 38

[Mark Mentovai]

Fixed on the trunk and 1_8 branch.

Comment 39

[Mark Mentovai]

Attachment: As checked in

Comment 40

[Mark Mentovai]

Regarding comment 28, this actually is a regression relative to 1.0 - also see comment 37.

Comment 41

[Daniel Veditz [:dveditz]]

Comment on attachment 211125 [details] [diff] [review]
As checked in

approved for 1.8.0 branch, a=dveditz for drivers

Comment 42

[Mark Mentovai]

On MOZILLA_1_8_0_BRANCH.

Comment 43

[Mark Mentovai]

*** Bug 322431 has been marked as a duplicate of this bug. ***

Comment 44

[Dave Liebreich [:davel]]

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?

Thanks

_Dave

Comment 45

[Timaeus Martinez]

(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?
> 
> Thanks
> 
> _Dave
> 
Hi,
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).
-Timaeus

Comment 46

[Darren Robinson]

will do, downloaded, and under test. will post more inc trace if problem reappears.

Comment 47

[Mark Mentovai]

*** Bug 316423 has been marked as a duplicate of this bug. ***

Comment 48

[Marc Rost]

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:1.8.0.1) Gecko/20060220 Firefox/1.5.0.1

Comment 49

[Marcia Knous [:marcia]]

verified on the 1.8.0.2 branch using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060306 Firefox/1.5.0.2. I tested on a Mac running 10.2.8 and did not experience any hangs. Adding keyword.

Comment 50

[Darren Robinson]

still working fine, appears to be fixed on 10.2.6

Comment 51

[planetlonk]

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?

Comment 52

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #51)
> Is it fixable?

It is fixed. The next release with this fix will be 1.5.0.2.

Comment 53

[planetlonk]

Thanks Gavin - I appreciate the update


> It is fixed. The next release with this fix will be 1.5.0.2.
> 

Comment 54

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 331217 has been marked as a duplicate of this bug. ***

Comment 55

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 331362 has been marked as a duplicate of this bug. ***

Comment 56

[:Gavin Sharp [email: [e-mail]]]

*** Bug 332469 has been marked as a duplicate of this bug. ***

Comment 57

[zug_treno]

*** Bug 332813 has been marked as a duplicate of this bug. ***

Comment 58

[:Gavin Sharp [email: [e-mail]]]

*** Bug 333596 has been marked as a duplicate of this bug. ***

Comment 59

[Catherine Whyman]

This doesn't seem to be fixed- E-Bay still crashes when you delete characters out too quickly- freezes up and crashes out

Comment 60

[Mark Mentovai]

Catherine, what version of Firefox are you using?  This will be fixed in 1.5.0.2, which isn't out yet.

Comment 61

[Catherine Whyman]

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

Comment 62

[Kevin Apgar]

*** Bug 330459 has been marked as a duplicate of this bug. ***