194945 - Caret isn't present when toggling to a composer window

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[Chris Petersen]

Build: 2003-02-24-03
Platform: All
Expected Results: Caret should be present in window
What I got: When toggling between two composer windows, each document's caret is
not present.

Steps to reproduce:

1) Create two new composer windows
2) Notice that when you click on the window's title bar, it comes to the front
of the stacking order and displays the document's caret. When switching between
the windows in this matter, the caret will appear.
3) Now, press command (ctrl) - 4 keys to toggle between these same windows.
4) Notice the caret doesn't appear in the top most window.

Comment 1

[Kathleen :Brade]

it's quite annoying not to be able to type when the window order changes (even
if I just cycle back to where I was)

fix should be pretty simple (1 line to focus the content area wherever the
window-menu toggling is done)

Comment 2

[Samir Gehani]

Composer triage team: nsbeta1+/adt3

Comment 3

[[e-mail]]

Attachment: Proposed patch

This makes it so that the previously focused DOM window is focused.

Comment 4

[Kathleen :Brade]

Comment on attachment 115633 [details] [diff] [review]
Proposed patch

assuming you've tested all the various window types etc...
r=brade

Comment 5

[jag (Peter Annema)]

Comment on attachment 115633 [details] [diff] [review]
Proposed patch

I'm wondering if this will make us focus the content window in browser if the
urlbar is selected...

What's happening here that's causing the caret to get lost? I just looked at
the equivalent of this in the browser, with two browser windows with google. If
I put focus in the urlbar, toggle to the other window, then back, focus is
still in the urlbar (though all of the text is selected, maybe we have some
special handler for this?), if I put it in the google input field, the caret is
gone.

focusedWindow.focus() seems like something that shouldn't need to be done (why
do we need to focus something that's already focused?). What's the real fix?

Comment 6

[[e-mail]]

Comment on attachment 115633 [details] [diff] [review]
Proposed patch

The current code always focuses the chrome window, which is always wrong in the
case of Composer, but may well also be wrong for other windows where we want to
focus the content when it was previously focused. So instead of blithely
focusing aWindow I want to focus the most recently focused frame of aWindow
instead.

Comment 7

[jag (Peter Annema)]

Comment on attachment 115633 [details] [diff] [review]
Proposed patch

sr=jag

Comment 8

[(not reading, please use [e-mail] instead)]

this sounds related to a html compose window regression, see bug #195798

Comment 9

[(not reading, please use [e-mail] instead)]

sorry, that bug is about new msg compose windows, not about toggling between two
existing ones.

Comment 10

[[e-mail]]

Fix checked in.

Comment 11

[Chris Petersen]

Verified in the 2003-04-10-08 Macho and Win32 2003-04-10-04 trunk builds.