Closed Bug 61853 Opened 24 years ago Closed 23 years ago

Location field can't be edited on skin switch

Categories

(Core Graveyard :: Profile: Migration, defect, P3)

Product:
Core Graveyard
Component:
Profile: Migration
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: zds, Assigned: hyatt)

References

(
URL
)

Details

(Keywords: smoketest) 

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (Windows NT 5.0; U)
BuildID:    2000120220

Location field, the thing containing URL of currently viewn page,
does not allow any editing. I can select parts of URL with mouse and change URL 
with drop-down menu, but not with keyboard. Clicking the field doesn't make the 
text cursor appear - it looks like the field couldn't be focused at all and 
hence it doesn't take any keyboard events. I tried restarting the browser and 
changing look'n'feel from classic to modern, but it didn't help.

Reproducible: Always
Steps to Reproduce:
1. Start the browser.
2. Click on location field.
3. Try typing anything from keyboard. Like deleting last character from URL.

Actual Results:  The URL doesn't change.

Expected Results:  The URL should change according to keypresses, i.e. if I 
press Delete key, the URL should shorten by one character.

I have also Netscape 6 previously installed on this computer, if that matters.
DUplicate.
Fabian.

*** This bug has been marked as a duplicate of 61849 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
I think this is different.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I checked it out, and this seems to have much the same as 61849.

Additional information:
-When I start browser, focus and text cursor are in location bar.
-If the bar ever loses it's focus, it can't get it back.
-Sometimes it allows me to paint parts of URL or select it with double-click. 
On this state, I can also get focus to location bar by first trying to 
activate the bar and then pressing right mouse button. When context menu pops 
up, bar gets focus. On these cases, I can drag or delete selected part 
sometimes.
-Even if I have focus on location bar, I can't move inside the field with arrow 
keys. Also, trying to paint something on the field or change the cursor 
location with mouse click makes me lose the focus.

wfm 2000120220 trunk win98
I found this with Linux too starting on 12/1.
win2000 I'm also seeing this.
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
smoketest blocker
Severity: critical → blocker
Keywords: smoketest
..and OS all
OS: Windows 2000 → All
*** Bug 61905 has been marked as a duplicate of this bug. ***
Text fields are Akkana's dept.  (And fwiw, I cannot reproduce this the
2000-04-08 linux nightly nor my tip linux build.)
Assignee: asa → akkana
I saw this a couple days ago in my tip build, but not anymore.  It was with xul 
textfields only, iirc, so probably not akkana's area.  But again, not seeing in 
winME tip or a win32 nightly.
i see it all the time w/ installed build ID 2000120408.
Scrollbars are also missing (bug 61852) and i crash on all pages with forms.
Hyatt made some changes to nsXBLService.cpp before all this showed up.
Can everyone delete their profile, etc. etc., download a new nightly, and 
ensure that there are still problems?
Renamed my .mozilla directory and could reproduce this with the sea installer of
2000120408.  However, the preinstalled tarball of 2000120408 was fine.  Hope
this helps.
OK, so, an installer issue only?
What I'm seeing is if I change the focus from the location bar to say the search
bar, for example, the cursor will not appear on the search bar nor can I change
it back to the location bar on the installed build.

fix landed. this was a packaging snafu.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
*** Bug 61959 has been marked as a duplicate of this bug. ***
Still broken for me in 2000120504 commercial build on win2k.  Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
it works in build 2000120421 however. Did forms.css vanish from the installed
builds again?
Sounds like it's fixed again?  In any case, the installer definitely isn't my area.
Assignee: akkana → ssu
Status: REOPENED → NEW
Component: Browser-General → Installer
QA Contact: doronr → gemal
With a new profile, this is fixed.  This is not fixed if migrating from a ns6rtm 
profile to 2000120504.  Where is forms.css supposed to be?
after creating a new profile, then switching back, everything seems to work, 
scrollbars and forms, with no crashing.
lowering severity to drop off smoketest radar.
Severity: blocker → critical
from looking at pinkerton's checkin yesterday, forms.css is supposed to be in 
bin\res\.

Changing Component to Profile Migration.
Assignee: ssu → dbragg
Component: Installer → Profile Migration
QA Contact: gemal → gbush
Sorry, not a migration issue. Forms.css did not exist in 4.x so it can't be
migrated.  Anyway, why is a file like forms.css dependent on the profile?
Shouldn't it be a "browser" file?

Reassigning to pinkerton since this seems to be a forms.css issue.
Assignee: dbragg → pinkerton
um, i already fixed this.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
This is fixed for me in 2000120508 with the profile I've been running for over a
week.
*** Bug 61880 has been marked as a duplicate of this bug. ***
Okay, I did the instructed trick, and now it works for me, with build 
2000120604. The trick was to make a new profile, use it a while and then change 
back.
vfy all platforms
12/7 and 12/8 builds
Status: RESOLVED → VERIFIED
reopening, i see this on a skin switch, and after a skin switch.  If i close and 
restart it fixes it
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
hyatt?
Assignee: pinkerton → hyatt
Status: REOPENED → NEW
->future
Summary: Location field can't be edited → Location field can't be edited on skin switch
Target Milestone: --- → Future
Blocks: 68973
patch in bug 60151 will fix this one as well
Patch in bug 60151 was just checked in.  Marking this bug as fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
build 2001052506
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.