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)
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)
2.56 KB,
patch
|
jaas
:
review+
jaas
:
approval-branch-1.8.1+
dveditz
:
approval1.8.0.2+
|
Details | Diff | Splinter Review |
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•19 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•19 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•19 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•19 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•19 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•19 years ago
|
||
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•19 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•19 years ago
|
||
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•19 years ago
|
Attachment #207775 -
Flags: superreview?(sfraser_bugs) → superreview+
Attachment #207775 -
Flags: review?(joshmoz)
Assignee | ||
Comment 8•19 years ago
|
||
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+
Updated•19 years ago
|
Assignee: mark → joshmoz
Status: ASSIGNED → NEW
Component: Keyboard Navigation → Widget: Mac
Flags: review+
Product: Firefox → Core
QA Contact: keyboard.navigation → mac
Version: unspecified → Trunk
Updated•19 years ago
|
Assignee: joshmoz → mark
Updated•19 years ago
|
Status: NEW → ASSIGNED
Attachment #208004 -
Flags: review+
Assignee | ||
Comment 9•19 years ago
|
||
Checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•19 years ago
|
Attachment #208004 -
Flags: approval1.8.1?
Attachment #208004 -
Flags: approval1.8.0.2?
Comment 10•19 years ago
|
||
Is this bug the same as 319747? Comment #14 in that bug makes me think so.
Assignee | ||
Comment 11•19 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•18 years ago
|
||
*** Bug 318283 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Attachment #208004 -
Flags: approval1.8.1? → branch-1.8.1?(joshmoz)
Attachment #208004 -
Flags: branch-1.8.1?(joshmoz) → branch-1.8.1+
Assignee | ||
Comment 14•18 years ago
|
||
*** Bug 319747 has been marked as a duplicate of this bug. ***
Comment 15•18 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•18 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 17•18 years ago
|
||
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+
Updated•18 years ago
|
Flags: blocking1.8.0.2+
Updated•18 years ago
|
Whiteboard: [rft-dl]
Comment 19•18 years ago
|
||
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
Comment 20•18 years ago
|
||
Removing dave's comment from the status whiteboard to get this off the query.
Whiteboard: [rft-dl]
Updated•18 years ago
|
Whiteboard: [rft-dl]
You need to log in
before you can comment on or make changes to this bug.
Description
•