Closed Bug 294476 Opened 19 years ago Closed 19 years ago

Text boxes ignore keyboard on opening URL from an external app

Categories

(Core Graveyard :: Widget: Mac, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hcbowman, Assigned: mark)

References

Details

(Keywords: fixed1.8.1, verified1.8.0.2, Whiteboard: [rft-dl])

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

With Firefox running but minimized, click on a URL in another application (e.g.
Apple Mail).  The active tab in Firefox will display the correct URL, but all
text boxes ignore entry.  This includes the search tool's text field and text
boxes on the URL.  Firefox must be minimized to observe this bug.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox.  Minimize the window.
2. Open Apple Mail.  Find an email with a link.  Click on the link.
3. Bring Firefox back to normal, then try to type in a textbox.

Actual Results:  
The textbox cannot be made active.  It doesn't matter whether the box is on the
webpage or on the toolbar (search tool, for example).  Because it is not active,
I can't type text in the textbox.  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.

Expected Results:  
I should be able to activate any textbox and enter text.

I've observed this since Firefox 10.0.1.
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.8) Gecko/20050511 Firefox/1.0.4
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.8) Gecko/20050511 Firefox/1.0.4
> 
> With Firefox running but minimized, click on a URL in another application (e.g.
> Apple Mail).  The active tab in Firefox will display the correct URL, but all
> text boxes ignore entry.  This includes the search tool's text field and text
> boxes on the URL.  Firefox must be minimized to observe this bug.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Open Firefox.  Minimize the window.
> 2. Open Apple Mail.  Find an email with a link.  Click on the link.
> 3. Bring Firefox back to normal, then try to type in a textbox.
> 
> Actual Results:  
> The textbox cannot be made active.  It doesn't matter whether the box is on the
> webpage or on the toolbar (search tool, for example).  Because it is not active,
> I can't type text in the textbox.  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.
> 
> Expected Results:  
> I should be able to activate any textbox and enter text.
> 
> I've observed this since Firefox 10.0.1.

I've observed this bug with OS X 10.3 and 10.4, Firefox versions 1.0.1 (not 10.0.1).
I've observed this on OS 10.3.9, FFX v. 1.0.4  The problem is temporarily
bypassed if you switch Caret Browsing (F7), or from the Pref. window.
could be related to bug 283050.
Component: Search → Keyboard Navigation
QA Contact: search → keyboard.navigation
Summary: Text box entry is ignored if I click a URL from Apple Mail → Text boxex entry is ignored if I click a URL from an external app
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006
(No IDN) Firefox/1.4.1

i see the issue too. giving focus to another app and back to ffox fixes it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Text boxex entry is ignored if I click a URL from an external app → Text boxes ignore keyboard on opening URL from an external app
This only happens if the window was active when it was collapsed.  Possibly some activate event is being suppressed when the window is expanded because nobody informed Mozilla when the window was collapsed.  I'll put this on my list.
Assignee: nobody → mark
Attached patch Activate windows being restored (obsolete) — Splinter Review
This fixes the bug by sending an NS_ACTIVATE event to windows that are being restored from the minimized state.  This is done on a kEventWindowExpanding Carbon event.

At the same time, I'm moving the rollup's Carbon event from kEventWindowCollapse to kEventWindowCollapsing.  kEventWindowCollapse was correct pre-OS X, but it is only sent when the window minimizes in response to the collapse box in the title bar.  (Remember WindowShade?)  That event is not sent when the window is minimized by pressing command-M, so the rollup never happens in that case.  (Try it: open a popup like a dropdown or contextual menu and press command-M.)  The proper event to use now is kEventWindowCollapsing, which is sent before the window minimizes for any reason.

kEventWindowExpanding is used instead of kEventWindowExpand for the same reason.  (It's not normally possible to receive kEventWindowExpand on OS X, because the collapse/expand button is not available when the window's minimized to the dock.)
Attachment #207774 - Flags: superreview?(sfraser_bugs)
Attachment #207774 - Flags: review?(joshmoz)
Status: NEW → ASSIGNED
Attached patch v1+a (obsolete) — Splinter Review
Oops, left out a break.
Attachment #207774 - Attachment is obsolete: true
Attachment #207775 - Flags: superreview?(sfraser_bugs)
Attachment #207775 - Flags: review?(joshmoz)
Attachment #207774 - Flags: superreview?(sfraser_bugs)
Attachment #207774 - Flags: review?(joshmoz)
Attachment #207775 - Flags: superreview?(sfraser_bugs) → superreview+
Attachment #207775 - Flags: review?(joshmoz)
Attached patch v1+bSplinter Review
This differs from the previous patch in two ways:

 - Send an NS_DEACTIVATE event when windows are being minimized.  Without this change, if there is only a single window and it is minimized, it retains focus.  This is undesirable.

 - Send the NS_ACTIVATE after a window is restored, not before.  When the NS_ACTIVATE came early, there were certain situations where it would cause the system to become confused (and send an extra kEventWindowExpanding event).  The whole app would hang for about five seconds.  Doing the NS_ACTIVATE on a kEventWindowExpanded Carbon event works just as well, and ensures that the window will already have been brought back.  The system will not become confused and will not hold us up for five (or any other number of) seconds.
Attachment #207775 - Attachment is obsolete: true
Attachment #208004 - Flags: review?(joshmoz)
Attachment #208004 - Flags: review?(joshmoz) → review+
Assignee: mark → joshmoz
Status: ASSIGNED → NEW
Component: Keyboard Navigation → Widget: Mac
Flags: review+
Product: Firefox → Core
QA Contact: keyboard.navigation → mac
Version: unspecified → Trunk
Assignee: joshmoz → mark
Status: NEW → ASSIGNED
Attachment #208004 - Flags: review+
Checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #208004 - Flags: approval1.8.1?
Attachment #208004 - Flags: approval1.8.0.2?
Is this bug the same as 319747? Comment #14 in that bug makes me think so.
I hope so, but I'm not positive it is (and I fear it's not).  I fixed this bug while I was trying to hunt down a way to reproduce bug 319747.  The symptomps are identical, but I'm not sure if 319747 has a different cause than this bug.  This bug was present in 1.0.x, and I think that we got worse about losing the keyboard following CFRunLoop, but I could be wrong.
*** Bug 318283 has been marked as a duplicate of this bug. ***
Attachment #208004 - Flags: approval1.8.1? → branch-1.8.1?(joshmoz)
Attachment #208004 - Flags: branch-1.8.1?(joshmoz) → branch-1.8.1+
Checked in on 1_8 branch.
Keywords: fixed1.8.1
*** Bug 319747 has been marked as a duplicate of this bug. ***
Mark, since Bug #319747 was closed, and you state "we had lots of focus and responsiveness issues that are hopefully now all cleaned up."
am i to assume that the bugs for which i was contributing info/data now resolved  with a new update 1.5.0.2 (perhaps?) or was this just a general blitz of older resolved bugs which are part of the latest update (1.5.0.1) - as i think the later is more likely (submitted for clarification only).
We have a tremendous amount of old stale bugs that became wastelands for people to post maybe-kinda-sorta-related issues to, and those bugs lost direction.  It's really hard to fix a moving target.  I think that at this point, we've either fixed all of the known loses-focus/can't-type/typing-causes-it-to-hang that debuted in 1.5, or we will have fixes for them for 1.5.0.2.  All of these issues have their own real bugs dedicated to them.  I'm only closing the fluff and moving targets.  If there are new issues that deserve attention, they belong in their own bugs.  I don't doubt that there are such issues, but nobody's going to notice them if they're introduced for the first time as comment 75 on a bug about something else.  Don't be afraid to file new if you find after searching Bugzilla that you've got a new issue.  We're friendly people, we don't bite.
Comment on attachment 208004 [details] [diff] [review]
v1+b

approved for 180 branch, a=dveditz for drivers
Attachment #208004 - Flags: approval1.8.0.2? → approval1.8.0.2+
Flags: blocking1.8.0.2+
On 1_8_0.
Keywords: fixed1.8.0.2
Whiteboard: [rft-dl]
Verified using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060301 Firefox/1.5.0.1. Adding relevant keyword.
Removing dave's comment from the status whiteboard to get this off the query.
Whiteboard: [rft-dl]
Whiteboard: [rft-dl]
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: