Closed Bug 32349 Opened 25 years ago Closed 23 years ago

Main pane loses focus on open-in-new-window

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.0

People

(Reporter: ltskinol, Assigned: saari)

References

()

Details

(Whiteboard: [nsbetadenied])

Browse to a page and select inside the browser window. The keyboard arrow keys work. Now right-click on a link and select Open in New Window. When the new window comes up, minimize it. Bring the original window back into focus with the window manager (I use auto-raise and auto-focus, but clicking on the title bar is equivalent). Now something other than the main pane has the focus, as the arrow keys no longer work, and you have to re-click in the main pane to get the arrow keys to work. This makes it harder to use Open in New Window, because you have to keep going back and clicking in the main pane to scroll to the next link.
Dupe of Bug 9701. ltskinol@edgebbs.com - I don't know what version you were using, but did you read the release notes for M14? http://www.mozilla.org/projects/seamonkey/release-notes/m14.html Gerv *** This bug has been marked as a duplicate of 9701 ***
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
I re-read the release notes again tonight, and don't see it. Sorry. The report was against nightly build 2000031716, but I've seen this problem for as long as I can remember. Certainly since M13. Sorry for not including that information. If I read it right, bug 9701 lists this as fixed as of mid February. Since I'm using a newer build than that, I'd like to re-open this bug. Please let me know if I'm on drugs.
This does look different from 9701 and is not working properly in recent nightly builds under NT Reopening bug. Changing OS to all and sending to evant handling for a look.
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → Event Handling
Resolution: DUPLICATE → ---
re-assigning to event handling owner
Assignee: cbegle → joki
QA Contact: asadotzler → janc
Knowing where focus should be is saari's domain.
Assignee: joki → saari
ltskinol@edgebbs.com - are you still seeing this problem on recent builds of Mozilla? Don't worry, I wont dupe it again ;-) Gerv
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → M17
Yes, the problem still remains as of the 2000041409 build.
moving to m18
Target Milestone: M17 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Context menus need to stop taking focus, this is messing up other things (commands) that look for the focused item.
Keywords: nsbeta3
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
nsbeta3-, wouldn't hold for this particular symptom, but should be fixed as part of fix for other more serious (plussed) bugs.
Whiteboard: [nsbeta3-]
Target Milestone: M21 → Future
Probably the same cause as bug 33844 bug 50509 may be related as well (though that doesn't involve context menus)
Updating QA Contact.
QA Contact: ckritzer → lorca
Target Mozilla 1.0
Target Milestone: Future → mozilla1.0
Changing Status for my reference. Was NSBETA3-. Anyone think this should be renominated?
Whiteboard: [nsbeta3-] → [nsbetadenied]
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
works for me on win2k. Still a problem on linux?
seems to workforme
Status: ASSIGNED → RESOLVED
Closed: 25 years ago23 years ago
Resolution: --- → WORKSFORME
QA Contact: madhur → rakeshmishra
QA Contact: rakeshmishra → trix
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.