Last Comment Bug 294476 - Text boxes ignore keyboard on opening URL from an external app
: Text boxes ignore keyboard on opening URL from an external app
Status: RESOLVED FIXED
[rft-dl]
: fixed1.8.1, verified1.8.0.2
Product: Core Graveyard
Classification: Graveyard
Component: Widget: Mac (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- normal with 2 votes (vote)
: ---
Assigned To: Mark Mentovai
:
:
Mentors:
: 319747 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-17 06:06 PDT by Cliff Bowman
Modified: 2009-11-21 15:09 PST (History)
6 users (show)
dveditz: blocking1.8.0.2+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Activate windows being restored (2.38 KB, patch)
2006-01-06 15:46 PST, Mark Mentovai
no flags Details | Diff | Splinter Review
v1+a (2.39 KB, patch)
2006-01-06 15:49 PST, Mark Mentovai
sfraser_bugs: superreview+
Details | Diff | Splinter Review
v1+b (2.56 KB, patch)
2006-01-09 11:59 PST, Mark Mentovai
jaas: review+
jaas: approval‑branch‑1.8.1+
dveditz: approval1.8.0.2+
Details | Diff | Splinter Review

Description Cliff Bowman 2005-05-17 06:06:53 PDT
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.
Comment 1 Cliff Bowman 2005-05-17 06:10:57 PDT
(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 Alex Maceda 2005-06-27 01:00:18 PDT
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 Fabio Russo 2005-10-10 07:24:12 PDT
could be related to bug 283050.
Comment 4 Fabio Russo 2005-10-10 07:27:48 PDT
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.
Comment 5 Mark Mentovai 2006-01-06 11:54:21 PST
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.
Comment 6 Mark Mentovai 2006-01-06 15:46:15 PST
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.)
Comment 7 Mark Mentovai 2006-01-06 15:49:02 PST
Created attachment 207775 [details] [diff] [review]
v1+a

Oops, left out a break.
Comment 8 Mark Mentovai 2006-01-09 11:59:09 PST
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.
Comment 9 Mark Mentovai 2006-01-09 14:21:05 PST
Checked in to trunk.
Comment 10 Josh Aas 2006-01-10 21:14:49 PST
Is this bug the same as 319747? Comment #14 in that bug makes me think so.
Comment 11 Mark Mentovai 2006-01-10 21:37:30 PST
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.
Comment 12 Mark Mentovai 2006-01-26 06:53:41 PST
*** Bug 318283 has been marked as a duplicate of this bug. ***
Comment 13 Mark Mentovai 2006-01-30 13:59:03 PST
Checked in on 1_8 branch.
Comment 14 Mark Mentovai 2006-02-07 13:18:59 PST
*** Bug 319747 has been marked as a duplicate of this bug. ***
Comment 15 Darren Robinson 2006-02-07 17:26:24 PST
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).
Comment 16 Mark Mentovai 2006-02-07 19:58:56 PST
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 17 Daniel Veditz [:dveditz] 2006-02-21 15:21:49 PST
Comment on attachment 208004 [details] [diff] [review]
v1+b

approved for 180 branch, a=dveditz for drivers
Comment 18 Mark Mentovai 2006-02-21 19:32:04 PST
On 1_8_0.
Comment 19 Marcia Knous [:marcia - use ni] 2006-03-01 17:49:44 PST
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.
Comment 20 Marcia Knous [:marcia - use ni] 2006-03-01 18:01:01 PST
Removing dave's comment from the status whiteboard to get this off the query.

Note You need to log in before you can comment on or make changes to this bug.