Closed Bug 319747 Opened 19 years ago Closed 19 years ago

Form fields and url field prevents cursor input - can't enter any text, slow, freeze, unresponsive

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 294476

People

(Reporter: finnh, Assigned: jaas)

References

Details

(Keywords: hang, helpwanted)

Attachments

(1 file)

sample of firefox hung
202.66 KB, text/plain
Details 
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

After using Firefox, browsing the internet, reading forums, etc., when I try to log in on a forum or Web application (like Oracle), I can't click the mouse cursor in a text field or type anything in the url field.  This happens frequently but not with every use of Firefox and with many different Web sites.  Sometimes when filling out a form by clicking on radio buttons, check boxes, etc., when I try to enter text into a field, the cursor won't "enter" and I can't type any text.  This seems to happen most often after hiding Firefox and then restoring it to full size.  The duration of time that Firefox is hidden varies.  Refreshing the page doesn't solve the problem.  I have to quit and reopen Firefox.  I didn't understand bug report #295654 completely, but it sounded like there was a similar problem.  I've had this problem with earlier versions of Firefox, too.

Reproducible: Sometimes

Steps to Reproduce:
1.  I don't know how to reproduce it.  That's why I've waited so long to report this problem.  It doesn't happen with any other browser.
*** Bug 319748 has been marked as a duplicate of this bug. ***
*** Bug 319749 has been marked as a duplicate of this bug. ***
*** Bug 319754 has been marked as a duplicate of this bug. ***
Maybe related to bug 319590, bug 269207 or bug 294476?
I have exactly the same problem ....
Yes, the bug I've reported is exactly similar to 319590, partially related to 269207 (url fields are disabled) and not at all related to 294476.  

(Sorry for the initial duplicate emails.  I was having problems submitting my report.)
*** Bug 319590 has been marked as a duplicate of this bug. ***
*** Bug 320004 has been marked as a duplicate of this bug. ***
*** Bug 320007 has been marked as a duplicate of this bug. ***
Summary: Form fields and url field prevents cursor input--can't enter any text → Form fields and url field prevents cursor input - can't enter any text, slow, freeze, unresponsive
*** Bug 319361 has been marked as a duplicate of this bug. ***
*** Bug 320283 has been marked as a duplicate of this bug. ***
(In reply to comment #11)
> *** Bug 320283 has been marked as a duplicate of this bug. ***
> 
I read the bug report and that doesn't sound to me like the same problem.


I am using firefox 1.5 and i have kind of the same problem : when I minimize a window in the dock and it comes out again it is not typable but closing the window and opening another window the problem is solved
(In reply to comment #13)
> I am using firefox 1.5 and i have kind of the same problem : when I minimize a
> window in the dock and it comes out again it is not typable but closing the
> window and opening another window the problem is solved
> 

Yes, exactly the problem I am reporting!
*** Bug 312713 has been marked as a duplicate of this bug. ***
Keywords: hang, helpwanted
No longer depends on: 314474
Severity: normal → major
Depends on: macdropdownhang
Version: unspecified → 1.5 Branch

*** This bug has been marked as a duplicate of 298502 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
No longer depends on: macdropdownhang
Resolution: --- → DUPLICATE
I do not understand how this could be a duplicate of 298502, since that bug is 10.2 specific.  I can reproduce this on a number of 10.4.3 machines.  If others can confirm this it should be reopened.
I can confirm that running os x 10.4.3 and firefox 1.5 gives the same problem
Re-opening to depends for now, given comment 18 and 19.
Status: RESOLVED → UNCONFIRMED
Component: General → Widget: Mac
Depends on: macdropdownhang
Product: Firefox → Core
Resolution: DUPLICATE → ---
Version: 1.5 Branch → 1.8 Branch
Assignee: nobody → joshmoz
QA Contact: general → mac
A number of duplicates mention this being a problem with the autocomplete popup appearing (goes away when there's no form history).
*** Bug 320283 has been marked as a duplicate of this bug. ***
*** Bug 320762 has been marked as a duplicate of this bug. ***
*** Bug 320757 has been marked as a duplicate of this bug. ***
I often have this problem in osx 10.2.8.  It occurs when a dropdown appears beneath the form field suggesting saved form information.  It seems to happen after typing the first letter.  Most often happens to me at google's search field, but I've seen it in many places.  
I often have this problem in osx 10.2.8.  It occurs when a dropdown appears beneath the form field suggesting saved form information.  It seems to happen after typing the first letter.  Most often happens to me at google's search field, but I've seen it in many places.  

P.S. -- This problem didn't happen at all before Firefox 1.5
Confirmed on the latest Firefox on my s-l-o-w Mac Mini.  I'm not sure what to do to reproduce it, but it happens regularly under heavy load.

Firefox has mouse focus, but for some reason, not keyboard focus.  Clicking on various widgets and textboxes eventually will restore keyboard focus, if the user is patient....

*** Bug 321437 has been marked as a duplicate of this bug. ***
*** Bug 321432 has been marked as a duplicate of this bug. ***
*** Bug 321419 has been marked as a duplicate of this bug. ***
*** Bug 321466 has been marked as a duplicate of this bug. ***
*** Bug 321654 has been marked as a duplicate of this bug. ***
*** Bug 321658 has been marked as a duplicate of this bug. ***
*** Bug 321817 has been marked as a duplicate of this bug. ***
confirming, based on all the duplicates
Status: UNCONFIRMED → NEW
Ever confirmed: true
Replicated on any text input field with stored history.  Hangs when suggested entries "div" appears. Mac 10.2.8.  

Work around: Firefox...Preferences...Saved Forms
Save form information = unchecked.  Clear History.
(In reply to comment #36)
> Replicated on any text input field with stored history.  Hangs when suggested
> entries "div" appears. Mac 10.2.8.  
> 
> Work around: Firefox...Preferences...Saved Forms
> Save form information = unchecked.  Clear History.
> 

That is actually bug 298502 (hang after popup or pulldown menu, only on 10.2.8). This bug is about an unresponsive textfield (without the autocomplete popup).
Work around proposed in comments #36 &37 appears to work for Google searches but not for the drop down menu associated with the back button. When there are somewhere between 5 and 10 items in this menu it goes blank and Firefox hangs up and needs to be restarted.
Workaround has no bearing on browser crashing while imputing credit card information on PayPal's virtual terminal.
If this bug is the same thing as 294476, then it is fixed.
*** Bug 318283 has been marked as a duplicate of this bug. ***
as my bug (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=318283">Bug #318283</a>) has been marked as a duplicate. i thought a clarification comment should be added here as comments here dont seem to cover how widespread this bug is.

The bug reported affects both 1.0 and 1.5, (apparently) any version of OS X, windows with or without focus, minimised or not, and where the firefox task is current, hidden or otherwise.

Also the bug affects firefox's toolbar wigits as well as those embedded in webpages. It is also extremely inconsistent, making it difficult to replicate. Inconveniently, it results in no 'crash log' as it technically didnt crash it, but instead hangs the task, forcing a manual end task ("Force Quit").
Darren, could you try Firefox 1.5.0.1rc1 from http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5.0.1rc1/mac/en-US at let me know if it's still a problem?

I'm sure that your bug isn't THIS bug, even though it was initially duped here.  THIS bug is ambiguous and it's sort of a moving target, because people keep turning it into other, similar bugs.  Maybe we should just close it.  YOUR bug is either something I've fixed or something I'm interested in learning more about.  Reopen your original bug or refile if it's not fixed in 1.5.0.1rc1.  Thanks.
will do, but i am interested to know if the version of firefox you suggest is a retrograde version of one of the two versions i already run. i have 1.5rc3 (Mozilla/5.0 Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8 Gecko/20051111 Firefox/1.5) alongside 1.0. if so i can confirm that the Issues discussed are sill present. if not i am happy to test the other version, but as it is rather inconsistent it may be a little while before i am sure that the bug is recurring.
1.5rc3 is equivalent to 1.5-release.

1.5.0.1rc1 is the release candidate for 1.5.0.1.  1.5.0.1 contains security and stability fixes relative to 1.5.
Ok, so i have now given 1.5.0.1 rc1 a good run, and finally got a hang... but this time seemes to be a different phenomena, so will report as a seperate bug, although it may have the same cause and be somehow related. However, the good news so far is that i havent managed to get the issues i (and others) first reported with the new version.

Okay, so if this is a dupe (which i still maintain it isnt - other bug #318283 also updated with the following comment) then its still with us, if not we still have a problem.

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

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.
Bug 294476 has a status resolved, and relates to a specific instance of the no input bug when browser was minimised or didnt otherwise get focus. Bug 319747 seemes to be a similar but is more wide ranging, and certainly has not been resolved. Bug 319590 does seem to have been a genuine dupe. Bug 269207 does seem to have related symptoms. there seems to have been a suggestion that has been rubbished that it may be related to the disk-sleep-fix. I know my system is set up to spin down discs when not required, will try disableing and see if i still get the same problems. Bug 298502 is reported as resolution FIXED (which clearly it isnt!), but does seeme to be related. My bug (Bug 318283) is possibly related and so has been left as duplicate for now).

As i say, going to try disabling spin-down to see if this has any effect on the problem as i cannot see any data related to it anywhere.
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. Please note this is DEFINITLY not the same bug as was originally posted at the top of this bug report. It has absolutley nothing to do with focus or minimization. Will reopen Bug 318283 if no-one has any objections as these bugs may be related, but are not the same.
Please generate a sampler trace for the slowdowns or hangs reported in this bug (this may require installing the developer tools on 10.2).
Does this bug only affect 10.2.8 users?
just found sampler, mallocdebug and objectalloc. will include any trace if/when found. this (and related bus) seems to be so irratic im not sure as to when or if any usable data can be found.

and in response to you second query. no it affects at least all versions of 10.2 (jaguar) and potentially (have not verified) other versions of OS X.

The problem we seme to have at the moment is that lots of similar bugs are being lumped together, either having the same symptoms, with different triggers or same triggers, but with varying symptoms. Some bugs that are mentioned in the above comments are reported as fixed and verified, but in reallity they cant be as the same problems are reoccuring.
Attached file sample of firefox hung — 
Attaching a Sampler from Mac OS X 10.3.9/ FF 1.5.0.1.  I think this is relevant to this bug and it looked like it, but I have no way of proving some event in another tab or window didn't suddenly cause the same symptom.  So, somebody who knows the guts, please have a look and obsolete this if it's not what we're looking for.
Attachment #210930 - Attachment mime type: application/octet-stream → text/plain
Bill: what page are you on when you see your hang (that you sampled)?
Sorry, Simon, I'm not 100% certain on that sampler, but I think it was:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174537

and it just happened again there.  I hamhandedly hit force-quit instead of sample this time but I'll get another one soon enough and verify.

Of course, being Bugzilla that page keeps changing, so it's probably not the ideal testcase.
We had lots of focus and responsiveness issues that are hopefully now all cleaned up.  Many of the bug reports in Bugzilla actually focus on multiple issues.  In an attempt to clean up my queue, I'm closing some of these focus bugs that are known to be fixed or cleaned up.  If you think that these bugs are being closed or duped in error, chances are there's already another bug out there specific to your issue.

Duping to bug 294476 because of comment 0: "This seems to happen most often after hiding Firefox and then restoring it to full size."

*** This bug has been marked as a duplicate of 294476 ***
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
One obvious distinction is that this bug pegs the CPU and hangs Firefox, whereas bug 294476 says, "If more than one browser window is open and
minimized, only the "active" (last accessed) window is affected.  All tabs in
the window are affected," which leads one to believe the tester on that bug could switch to another window in order to make this determination.  If what I'm seeing is truely this bug then it would be impossible to switch to another window to do any testing as Firefox is hung.
That's not what this bug was initially about.  You may be interested in bug 318283 or some other bug, but this one has been abused and has become such a mishmash of other problems that it no longer makes any sense to leave it open.

One issue per bug, please!  If you're having another focus/responsiveness problem, we probably already have another bug for it.
To the best of my knowledge, this bug has NOT been resolved, even with the new version of Firefox I am using, version 1.5.0.1. The problem can be averted by working with "preferences," so that Firefox does not retain memory of prior searches. Absent that workaround, the bug is still alive and well.

Oscar Jaeger alias enoughtoil
February 7, 2006
That is bug 318283.
This is bug 294476.
(In reply to comment #57)
> That's not what this bug was initially about.

Uh, OK.  The hang keyword and the 'slow, freeze, unresponsive' summary made me think this was about a hang on forms which bug 294476 isn't, at least explicitly.

> You may be interested in bug
> 318283 or some other bug

The patch over there says:

  +#if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_3

so not relevant to my 10.3.9 system, I think. 

I understand hard-to-reproduce bugs can get rather nebulous and unuseful but the symptoms should match on a DUPE resolution or at least a root cause should be identified.  If I'm just misunderstanding, any clarification might help others who come across this issue in the future.  Maybe the same root cause created both sets of symptoms?  If so, great, let's document that here.
*** Bug 334026 has been marked as a duplicate of this bug. ***
this bug is definitely NOT RESOLVED and is definitely not related to bug 298502.

Using Firefox 1.5.0.4 on OS X 10.4.6.

I've tried using Deer Park as well but have the same issue.

The bug as I see it is the following:

Open several Firefox windows, one containing a form with some text fields, and then minimize them to the Dock. Make the Finder or another application "active" so that Firefox and its windows stay open (minimized) but are running in the background.

Wait a minute or two and then go back to Firefox and un-minimize the window with the text fields. Chances are all text fields including the address bar will be unresponsive, i.e., you can try to click in them to force the cursor there and make the textfield active but nothing, not even typing, has any effect. To get the textfields working again you need to click off the window (make it inactive without minimizing) and then click on it again to make it active. This seems to bring the window and all its widgets back in focus and the textfields work again. Needless to say this is annoying as hell.

I would be very curious to hear if those having this same problem are also using any of Unsanity's haxies such as FruitMenu or WindowShadeX. On a whim I added Firefox to Unsanity's Application Enhancer Exclude List so that the haxies ignore Firefox. While I've only been testing this for a few minutes it seems as though I no longer experience the bug. Yet when running Safari and Camino with the haxies I do not experience the bug.

Is it possible that Firefox handles window focus differently than Camino/Safari that would cause it to break when used with Unsanity's haxies?

(In reply to comment #62)
> this bug is definitely NOT RESOLVED and is definitely not related to bug
> 298502.

I described experiencing a behavior similar to what you're seeing, in bug 339482 comment 31 (although I said there that browser restarting was required, lately when this happens to me, switching to another app and back again is sufficient).

I'm not using Unsanity's haxies.
Uri, if I'm not mistaken, the problems you're experiencing were on the 1.8[.1] branch (Firefox 2), and it seems that Brian's working with 1.8.0 (Firefox 1.5).

Brian, how are you minimizing the windows?  Command-M?  Clicking the yellow orb?  How are you raising them?  Clicking on their individual dock icons?  I think you'll need to try to reproduce this with APE and other system-modifying things turned off.
(In reply to comment #64)
> Brian, how are you minimizing the windows?  Command-M?  Clicking the yellow
> orb?  How are you raising them?  Clicking on their individual dock icons?  I
> think you'll need to try to reproduce this with APE and other system-modifying
> things turned off.

Usually by double-clicking on the title bar or Command-M. 

When using WindowShadeX I just double-click on the menu bar again in order to un-minimize the window.

Otherwise, with APE disabled I un-minimize them by clicking on their dock icon.

So far, with APE disabled for the last 4 hours, I haven't encountered the bug even though I'm working as usual.

So I am very inclined to think that somehow APE and Firefox don't play nice together.

Note that Safari and Camino do not have this issue and work fine with APE/WindowShadeX.

So I'm torn, as I hate working without WindowShadeX, but I hate using Firefox with the frequent bug occurence.

I really wish Camino was able to use FF extensions.

well for the past day and a half i've been using Firefox with APE enabled, but Firefox is specified in its Master Exclude List. Essentially this means APE does not "enhance" Firefox so that WindowShadeX is not applied when minimizing a Firefox window and instead it's passed to the system window manager.

I have not had one occurrence of the aforementioned bug, whereas before (with Firefox not excluded from APE) the bug would occur at least a dozen times a day.

It certainly seems like the Firefox and APE combo are problematic.
Brian, thanks for your input.  Have you notified the developers of APE?
(In reply to comment #67)
> Brian, thanks for your input.  Have you notified the developers of APE?

No I haven't. Firefox is the only app that has these issues so I'm assuming it's something related to how Firefox manages windows and their status (e.g., active, inactive, minimized, etc.).

No other browser (Safari, Camino, Opera, Omniweb) has this issue so it's hard for me to believe that APE is the problem.

Am I wrong for concluding this?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: