Caret isn't present when toggling to a composer window

VERIFIED FIXED

Status

SeaMonkey
Composer
VERIFIED FIXED
15 years ago
13 years ago

People

(Reporter: Chris Petersen, Assigned: jag (Peter Annema))

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3])

Attachments

(1 attachment)

(Reporter)

Description

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

15 years ago
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)
Keywords: nsbeta1

Comment 2

15 years ago
Composer triage team: nsbeta1+/adt3
Assignee: composer → jaggernaut
Keywords: nsbeta1 → helpwanted, nsbeta1+
Whiteboard: [adt3]

Comment 3

15 years ago
Created attachment 115633 [details] [diff] [review]
Proposed patch

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

Updated

15 years ago
Attachment #115633 - Flags: superreview?(jaggernaut)
Attachment #115633 - Flags: review?(brade)

Comment 4

15 years ago
Comment on attachment 115633 [details] [diff] [review]
Proposed patch

assuming you've tested all the various window types etc...
r=brade
Attachment #115633 - Flags: review?(brade) → review+
(Assignee)

Comment 5

15 years ago
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?
Attachment #115633 - Flags: superreview?(jaggernaut) → superreview-

Comment 6

15 years ago
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.
Attachment #115633 - Flags: superreview- → superreview?

Updated

15 years ago
Attachment #115633 - Flags: superreview? → superreview?(jaggernaut)
(Assignee)

Comment 7

15 years ago
Comment on attachment 115633 [details] [diff] [review]
Proposed patch

sr=jag
Attachment #115633 - Flags: superreview?(jaggernaut) → superreview+
this sounds related to a html compose window regression, see bug #195798
sorry, that bug is about new msg compose windows, not about toggling between two
existing ones.

Comment 10

15 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

15 years ago
Verified in the 2003-04-10-08 Macho and Win32 2003-04-10-04 trunk builds.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.