Closed Bug 307355 Opened 19 years ago Closed 19 years ago

[splitwindow] arrow keys break in second firefox window

Categories

(Firefox :: General, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 305032

People

(Reporter: syskin2, Assigned: jst)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050907 Firefox/1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050907 Firefox/1.4 Caret doesn't move in urlbar/searchbar. Reproducible: Always Steps to Reproduce: 1. Set homepage to about:blank 2. Start FF 3. Use desktop shortcut to start another FF window 4. Use arrow keys in urlbar or searchbar Actual Results: Left/right arrows are ignored Expected Results: Caret moves :) Paste doesn't work either. It looks like a new version of the evil caret bug.
Current regression window: 2005.09.06.07 - works (nightly) 2005.09.07.03 - fails (pacifica build) 2005.09.07.06 - still fails (nightly)
Keywords: regression
Also: Works in 7/30 Broken in 7/31 Splitwindow broke it, we fixed it for a while, then regressed it again.
Another one like bug 305032, but not fixed by the recent patch in there. Investigating.
Flags: blocking1.8b4?
Summary: arrow keys break in second firefox window → [splitwindow] arrow keys break in second firefox window
We need to understand which of the splitwindow changes to ESM and other focus sensitive areas were necessary and which weren't so deliberate.
Assignee: nobody → jst
This was caused by splitwindow, but I don't think by changes in ESM. When I use the inner window instead of the outer window it fixes bug 305032 but not this one. Yet the regression window indicates it's a splitwindow change.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: splitwindows
not going to block b4 for this but we do want to get it for b5. bsmedberg says this works fine for new windows launched from external apps (good news).
Flags: blocking1.8b5+
Flags: blocking1.8b4?
Flags: blocking1.8b4-
This worksforme with a branch build from MOZ_CO_DATE="Thu Sep 1 03:00:00 CDT 2005" on Linux and with a trunk build from Sep 2. Do I need to be looking at a more recent build?
(In reply to comment #7) > This worksforme with a branch build from MOZ_CO_DATE="Thu Sep 1 03:00:00 CDT > 2005" on Linux and with a trunk build from Sep 2. > > Do I need to be looking at a more recent build? Use as more recent build. It was temporarily fixed but the fix was wrong because it 1) didn't deal with the core causality and thus 2) caused other focus things to break. So the checkin on 9/6 to restore other focus bugs sent it back to its post-splitwindow state.
*** Bug 307528 has been marked as a duplicate of this bug. ***
Perhaps related to this bug: In Adblock Preference window, the left and right arrows don't works in the "New Filter" textbox. (Firefox 1.5 Beta 1 rc; Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050907 Firefox/1.4) But works fine in Deer Park of just 2 days before: (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050905 Firefox/1.0+)
*** Bug 307991 has been marked as a duplicate of this bug. ***
Please retest in tomorrow's trunk builds (now that bug 305032 has been fixed)?
Depends on: 305032
Fixed by the check-in for bug 305032.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Duping this to get this off my radar.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** This bug has been marked as a duplicate of 305032 ***
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.8b5+
You need to log in before you can comment on or make changes to this bug.