Closed Bug 12051 Opened 25 years ago Closed 25 years ago

[FEATURE] Focus not saved when switching between windows

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: davidm, Assigned: saari)

References

Details

(Whiteboard: [PDT+] URL bar and textareas are misbehaved)

Attachments

(1 file)

patch for nsHTMLTextAreaElement.cpp
1021 bytes, patch
Details | Diff | Splinter Review
When you switch between windows the focus is not saved. ( There is a comment in the code saying that also ;) ) This is causing me problems in that I give focus to an edit field but when the window is activate the focus is lost.
Assignee: trudelle → danm
reassigning to danm for triage, cc saari
phillip, can you check all platforms for results..thanks!
i did this across platforms with the 8-16-99 build: 1. open apprunner. 2. launch editor. click anywhere and start to type. 3. hit alt-tab or click on another window somewhere 4. alt-tab back or click on the editor window. 5. start typing again. on all 3 platforms, typing resumed where it left off. so i am unsure of the problem. davidm, could you provide some steps-to-reproduce?
On the mac, but the focus in the location field. Open a new browser window from the window. Click on the title bar of the old window The focus should be back in the location editfield. Same thing occurs one pages with forms.
Blocks: 12673
Target Milestone: M13
Assignee: danm → saari
Target Milestone: M13
A fix for this should fall out of Chris' current focus work.
Blocks: 16950
Status: NEW → ASSIGNED
Target Milestone: M12
House cleaning, targeting M12, will close when I land
Target Milestone: M12 → M13
This did not get fixed by my landing, since I'm tracking previously focused things on a global application level, not on a "window" level. I think I may be able to work this into the command dispatcher, which is already living at the window level.
This is the closest `focus' bug I could find; am I describing the same problem, or should the following become another bug? 1. Launch Apprunner 2. Click on the (tree widget?) gizmo that has the folders/bookmarks/etc. 3. scroll up and down with the arrow keys (this works) 4. Minimize apprunner, then restore it. 5. scroll up and down with the arrow keys Expected: I move up and down the gizmo that has the bookmarks/etc. Actual: I move up and down the page loaded (no frames) or nothing seems to have focus (frames). Occurs on win98(non-2nd ed), 1999112508
giving me rest of phillips open qa contact bugs, sorry for spam
Blocks: 21151
Priority: P3 → P1
Summary: Focus not saved when switching between windows → [FEATURE] Focus not saved when switching between windows
OS: Mac System 8.5 → All
Hardware: Macintosh → All
I just came to Mozilla to write up this very bug in build 1999122608. If you put the input focus to a text box, like the additional comments box here, switch to another window and come back, the cursor remains in the box but typing cannot happen until you click back in the box again.
*** Bug 22752 has been marked as a duplicate of this bug. ***
*** Bug 23168 has been marked as a duplicate of this bug. ***
*** Bug 23614 has been marked as a duplicate of this bug. ***
*** Bug 23793 has been marked as a duplicate of this bug. ***
Target Milestone: M13 → M14
moving non-showstopper bugs to m14
Blocks: 15681
Keywords: beta1
Putting on pdt+ radar for beta1.
Whiteboard: [PDT+]
*** Bug 25536 has been marked as a duplicate of this bug. ***
*** Bug 25871 has been marked as a duplicate of this bug. ***
*** Bug 24630 has been marked as a duplicate of this bug. ***
*** Bug 26068 has been marked as a duplicate of this bug. ***
*** Bug 25773 has been marked as a duplicate of this bug. ***
Due to this problem, IME won't work. While conversion is on, Japanese IME will invoke other new window that lookup choice region for displaying candidates of word conversion. The window of some IMEs gets an input focus. When the window is closed, it is expected the input focus is back to the original input field.
Blocks: 25348
*** Bug 26232 has been marked as a duplicate of this bug. ***
*** Bug 26699 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] → [PDT+] 2/14 working on this now, will take another day at least
Marking uber bug fixed. URL bar is still cranky on MacOS and Win32, but I don't think that is PDT+ so file a seperate bug on that (if we don't fix it first).
Marking uber bug fixed. URL bar is still cranky on MacOS and Win32, but I don't think that is PDT+ so file a seperate bug on that (if we don't fix it first).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Nope, sorry. I'm still seeing this in the 2/14 release build. Click in a bugzilla field, type something, move the mouse out of the window (lose focus) and back in (regain focus) and type something -- nothing goes to the textarea, and spaces will page the enclosing page down.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 27685 has been marked as a duplicate of this bug. ***
Neat, that is the second place where things are confused. If you type in the email field of a query it works, but not in the textarea for comments. Looks like there is something different about the URL bar and textareas... Grrr. I'm removing the PDT+ as I consider these deviant edge cases.
Whiteboard: [PDT+] 2/14 working on this now, will take another day at least → URL bar and textareas are misbehaved
After discussion with saari, putting back the PDT+ -- if you're typing in a bugzilla text area (like this one) and leave the window for any reason, the focus is lost and you have to click back into the textarea to resume typing, which doesn't seem like a deviant edge case.
Whiteboard: URL bar and textareas are misbehaved → [PDT+] URL bar and textareas are misbehaved
Blocks: 25135
I'm not sure this is the exact point that solves Textarea problem, but I found that nsHTMLTextAreaElement::HandleDOMEvent() does not call SetFocus() for TextArea. nsHTMLInputElement::HandleDOMEvent() calls SetFocus() for Text Field. This is a difference between TextArea and TextField. I attached a simple patch. Please review carefully.
Nice work, I just came up with an equivalent patch about 10 minutes ago! I really, really, really appreciate you looking at this. I'm pretty thrilled that someone else out there is willing to work on this!!! I'll post my patch in a sec...
*** Bug 23982 has been marked as a duplicate of this bug. ***
Fixed.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Verfied 022216
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: