Closed
Bug 146853
Opened 22 years ago
Closed 21 years ago
location bar unselectable when new window is spawned
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 146604
People
(Reporter: mbokil, Assigned: joki)
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 BuildID: 2002052306 When opening new blank window via the pull down menu or CTRL-N sometimes I am unable to select the URL location. The URL location bar will not accept focus and the newly spawned window must be closed. Reproducible: Sometimes Steps to Reproduce: 1. Open a new blank window CTRL-n. 2. Click in URL location bar. 3. The URL location bar should not respond. Actual Results: The newly spawned window is unusable since the location bar will not accept focus and a URI cannot be entered. Expected Results: Focus should have switched to the URL location bar and a blinking cursor should have appeared allowing text to be entered. This appears to be an intermittent problem with the latest 1.0 RC3 build I downloaded.
Did you perform a clean install (uninstalling first) or install over an older build?
Reporter mailed: -- yes, I removed everything but my address book and bookmark.html file. trashed it all and then installed RC3 cleanly. -- Reporter: This wasn't exactly what i meant... i meant: did you perform an uninstall - in the installation directory where the application is? (For instance via control panel) It seems you created a new profile, but may have had an older version of mozilla itself still installed somewhere? What happens if you uninstall first, and then install?
Comment 3•22 years ago
|
||
This bug is a duplicate, but I cannot seem to hunt it down. stay tuned ;) I'll find it eventually.
Comment 4•22 years ago
|
||
I have found the bug I was looking for. bug 126843 - Occasionally unable to get Focus set to URL bar and other text fields Although I am almost certain this is a duplicate, I will someone else decide if it is indeed a dupe. The specific steps/problem you report here appears to be the same, but please let us know if it is not. --> Leaving Unconfirmed for now
This maybe a duplicate of 146604. http://bugzilla.mozilla.org/show_bug.cgi?id=146604
Comment 6•22 years ago
|
||
2 Ryan Pertusio I'm not sure about real equivalence with bug http://bugzilla.mozilla.org/show_bug.cgi?id=126843 BeOS implementation of nsWindow::SetFocus(aRaise) was dropped on half-way. And this bug happened ther due to two different reasons: 1) Mozilla for BeOS was fallen in infinite loop on SetFocus when processed both cases for aRaise==PR_TRUE/PR_FALSE without any additional condition check 2)When focus setting was totally disabled for PR_TRUE - in some special test-builds. Though, in second case URL-bar was accessible after right-clicking on it. (Now there is patch for BeOS with fices both cases)
Comment 7•22 years ago
|
||
Err, I believe the bug I was really looking for was bug 82534 (Cannot type in URL/Address/location bar or text boxes - no caret/cursor) Even so, this bug is slightly different from bug 82534, in that this bug doesnt assume that prior Mozilla windows are minimized. This bug, however, indicates the problem can occur while a window is in focus (the ability to select File --> New --> Navigator Window) As far as I can tell, this is not a duplicate, as I thought previously. I apologize
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 8•21 years ago
|
||
Is this still an issue? WFM Mozilla 1.3, Windows 2000.
Comment 9•21 years ago
|
||
> This maybe a duplicate of 146604. summaries are almost identical. marking dupe. *** This bug has been marked as a duplicate of 146604 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•