Spun off from bug 271194 comment 36. When following the test case described in bug 271194, Seamonkey on branch 1.8 and trunk display an incorrect address in the URL bar - not the address of the content shown.

Just for ease, I'll go ahead and attach the testcase Jesse made for Bug 271194 to this bug. Thanks for your all your help Kai.

Why didn't the fix in bug 271194 fix seamonkey? The patch was to shared code. At a quick glance the tabbrowser and browser/navigator onSecurityChange code looks equivalent in seamonkey and firefox. Neil, biesi: you both appear to be on the seamonkey council, you'll probably want to figure out the difference for your 1.0 seamonkey release.

This appears to be a "timing" issue. Both the browser status filter and the security UI hook in to the location change notification. However, the security UI's hook is firing first, so it shows the modal dialog before the URL bar changes. Then the timeout in the first window fires, which loads a new page, firing more security UI. Then the URL bar updates happen, but in reverse order :-(

OK, so the reason this works in Firefox is that it verifies that the security UI has been initialized before it adds the URLbar progress listener. However to fix other tabbrowser bugs we moved up the progress listener initialization...

I broke out the constructor into an init method to call it from tabbrowser, for the case that the first browser doesn't have a docShell yet. Naturally I init it before adding the first progress listener ;-)

Fix checked in.

vrfy fixed: winxp, trunk, 2005110908 - urlbar is right, lock is open, www.mozilla.org is showing.

Comment on attachment 202229 [details] [diff] [review] Proposed patch suite-only security fix.

sounds like this is fixed on branch, removing blocking nominations.