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
(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 ***
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.
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 :/
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!
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 ***
Go Michael !