Text boxes ignore keyboard on opening URL from an external app

RESOLVED FIXED

Status

Core Graveyard
Widget: Mac
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: Cliff Bowman, Assigned: Mark Mentovai)

Tracking

({fixed1.8.1, verified1.8.0.2})

Trunk
PowerPC
Mac OS X
fixed1.8.1, verified1.8.0.2
Bug Flags:
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rft-dl])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

12 years ago
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.
(Reporter)

Comment 1

12 years ago
(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).

Comment 2

12 years ago
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.

Comment 3

12 years ago
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

Comment 4

12 years ago
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
(Assignee)

Comment 5

12 years ago
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
(Assignee)

Comment 6

12 years ago
Created attachment 207774 [details] [diff] [review]
Activate windows being restored

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)
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 7

12 years ago
Created attachment 207775 [details] [diff] [review]
v1+a

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)

Updated

12 years ago
Attachment #207775 - Flags: superreview?(sfraser_bugs) → superreview+

Updated

11 years ago
Attachment #207775 - Flags: review?(joshmoz)
(Assignee)

Comment 8

11 years ago
Created attachment 208004 [details] [diff] [review]
v1+b

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)

Updated

11 years ago
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

Updated

11 years ago
Attachment #208004 - Flags: review+
(Assignee)

Comment 9

11 years ago
Checked in to trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Attachment #208004 - Flags: approval1.8.1?
Attachment #208004 - Flags: approval1.8.0.2?

Comment 10

11 years ago
Is this bug the same as 319747? Comment #14 in that bug makes me think so.
(Assignee)

Comment 11

11 years ago
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.
(Assignee)

Comment 12

11 years ago
*** Bug 318283 has been marked as a duplicate of this bug. ***
Attachment #208004 - Flags: approval1.8.1? → branch-1.8.1?(joshmoz)

Updated

11 years ago
Attachment #208004 - Flags: branch-1.8.1?(joshmoz) → branch-1.8.1+
(Assignee)

Comment 13

11 years ago
Checked in on 1_8 branch.
Keywords: fixed1.8.1
(Assignee)

Comment 14

11 years ago
*** Bug 319747 has been marked as a duplicate of this bug. ***

Comment 15

11 years ago
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).
(Assignee)

Comment 16

11 years ago
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+
(Assignee)

Comment 18

11 years ago
On 1_8_0.
Keywords: fixed1.8.0.2

Updated

11 years ago
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.
Keywords: fixed1.8.0.2 → verified1.8.0.2
Removing dave's comment from the status whiteboard to get this off the query.
Whiteboard: [rft-dl]
Whiteboard: [rft-dl]

Updated

8 years ago
Component: Widget: Mac → Widget: Mac
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.