138805 - New Version of: Mozilla generally ignores URL input untill DNS resolving is done and address is connected successfully

Status: VERIFIED DUPLICATE of bug 104778

(SeaMonkey :: Location Bar, defect)

Description

[Deleted User]

Introduction:

This error can be seen as a duplicate of 104778--and all the duplicates of that
error. But, because the new RC1 is affected also, and because the previous
descriptions do not really describe the internal mechanism that leads to this
behaviour, I decided to re-enter this bug with better explanation of what the
heck the error is about.

Further info:

I went to the "advanced bug entry form" but could not select the mozilla version
there. The select box contained only "other" (is that a joke?). But, as I found
out, the error hits all newer versions up to the RC1 that really didn't do me
any favour. Instead, I previously was able to reduce the compilation result to
245Mb, the RC1 (again) stays like a rock at 1.1Gb :( I switched back to 0.9.9.


Now to the error (misbehaviour, mismanagement, illogic in the registry model,
[...]):

Mozilla does not register any content in the URL bar (no matter if related to
new, old, used, or unused windows or tabs) untill a connection is established
successfully. Only the successful connection pushes mozilla to register the
content in the URL bar with the related window or tab. 

If you use only window mode you may not get aware of this principial
misbehaviour because all the windows have their own URL bar. If you use tab mode
you may switch between the tabs and, thus, enforce mozilla to switch the content
in the URL bar accordingly. Because the tabs may not be registered as "active"
but still be considered as "inactive" the URL bar shows "about:blank" (It should
at least show nothing instead of this message). This problem even appears if you
already entered something into the URL bar but did not wait for connect because
then the information was just not registered with the tab internally. Instead,
it got forgotten while switching between tabs.

You may say that when you confirm the input then mozilla cares about it. But
this is only half true. If you switch to another tab and back, and the
connection is not established in the meantime, the URL bar does not show your
input but "about:blank" untill connection gets established. Only then your typed
in address appears new in the URL bar. This means that mozilla itself knows the
address and tries to connect to it but the tab and the URL input are still not
registered together untill successful connection.

You can prove that this general behaviour even hits window mode when you open a
link into a new window. The URL bar of the new window stays empty untill the
connection is succesful. Only after the successful connection the URL bar
suddenly shows the address. This is too late. If you closed the original window,
you lost information about the link completely.

What has to be done:

1. First of all skip any status messages like "about:blank". Nobody asks for
that, but it disturbs enormously. The hint mode "about:" is only an offer to the
user if he wishes to get information. Thus, it shall never appear automatically,
no matter when or where. This error is actually a very own error, I don't
understand why you previously assigned this error to 104778.

2. The URL bar must be monitored. This means that mozilla should register any
input, typed into the URL bar, with the related object (window or tab) at the
time of entering (synchronously or live).

So, I hope that the problem is now clear enough to find the error (or how you
would call that) in the code. 

Thanks for reading

Dennis

Comment 1

[John Levon]

(KaiL)

If you have some comments that you think will help fix the problem,
please add it as a comment to that bug. (Also please be careful to
keep to one issue per bug report).

Thanks !

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

Comment 2

[Deleted User]

This error can be seen as a duplicate of 104778--and all the duplicates of that
error (at least the moderator is not able to look ahead of this). But, because
the new RC1 is affected also, and because the previous descriptions do not
really describe the internal mechanism that leads to this behaviour, I decided
to re-enter this bug with better explanation of what the heck the error is about.

Comment 3

[John Levon]

Can QA do something here ? The reporter was not very happy, to say
the least. I can't see much useful with this bug since it reports
several already known bugs :/

Comment 4

[Deleted User]

Post our discussion here and let the readers decide! It's all in there.
I can only comment that the other bug messages are not really covering the
acutal bug while this is a try to sum up and solve. Maybe you should mark the
others as "duplicate" of this message. It would help more than keeping the other
descriptions.

Interestingly somebody marked this message as "normal". Are you already
that resignated that you only count the crash-bugs? The users are really
disturbed by the described behaviour. And, that this bug is not solved since
releases shows that you are not really interested in the opinion of your
users!

Comment 5

[Michael Lefevre]

with or without the improved description, this is still a duplicate of bug
104778. by this time, that bug has a bunch of extra information, votes,
duplicates, and a code patch, so there's definitely no chance that this report
is more important than that one.

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

Comment 6

[John Levon]

Go Michael !