31802 - unable to type in Location field after visiting secure site

Status: VERIFIED DUPLICATE of bug 32120

(SeaMonkey :: UI Design, defect, P3)

Description

[sairuh (rarely reading bugmail)]

this is very weird --it happened on my machine (hopey.mcom.com), running redhat
linux (kernel v2.2.12-20) --when using either AfterStep or Enlightenment as
window managers. found while using the beta (non-trunk) optimized commercial
bits 2000.03.13.19-nb1b.

to repro:
1. type the above url, ie, "junruh" into the Location textfield.
2. hit Enter key. you might get a dialog saying that https is not a registered
domain --this a known regression bug (dunno the number, alas).
3. try to go to another page by typing a URL in the Location field.

result: cannot enter text into the Location field.

workaround: use the Open Web Location dialog. however, this is still a
regression.

Comment 1

[Paul MacQuiddy]

the warning 'https is not a registered protocol' is not a bug, because those are
mozilla builds that don't contain security

also, I think these builds didn't get packaged correctly, so I'm not sure any
testing with these builds are valid

Comment 2

[Paul MacQuiddy]

sarah informed me that she was using netscape commercial bits, so I stand
corrected :-)

Comment 3

[sairuh (rarely reading bugmail)]

dang. going to a secure page no longer causes the Location field to be
inaccessable. tested w/2000.03.16.05 opt comm bits (beta1 branch).

but i've managed to find another way to make the Location field inaccessible:

1. open another browser window.
2. in Location field, double-click to select all the contents.
3. overwrite current contents by typing www.supersnail.com, then hit Enter key.
4. click on link for Comix Creators.
5. once that page loads, go to the Location field to type something else.
result: you can't. the I-bar cursor is there when you mouseover, but unable to
click into field, or edit it...

i wonder if i should just mark this one WFM, then open another bug...? would
rather not morph this one, but am not sure if the failure am seeing now is
related to the original problem...

Comment 4

[sairuh (rarely reading bugmail)]

hokay, am gonna split the latter problem into another report,  bug 32120. mark
wfm.dup as needed, tho'... :-)

Comment 5

[shrirang khanzode]

I visited "https://junruh", browser around and then went to another site. But I 
did not see the cursor problem. Used today's linux commercial beta1 bits.

Comment 6

[sairuh (rarely reading bugmail)]

just spoke with shrir about this --i can repro this *erratically* when i enter
http://junruh (argh)--but i cannot repro it when entering https://junruh...
methinks it might be best to simply make this a dup of 32120. but if anyone
thinks this is a seperate issue, do lemme know.

*** This bug has been marked as a duplicate of 32120 ***

Comment 7

[shrirang khanzode]

Sorry for the spam, changing QA contact.

Comment 8

[sairuh (rarely reading bugmail)]

verif.