Closed Bug 313335 Opened 19 years ago Closed 19 years ago

URL bar displays wrong address, after going from secure to insecure page (or vice versa)

Categories

(SeaMonkey :: Security, defect)

1.8 Branch
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: KaiE, Assigned: neil)

Details

(Keywords: fixed1.8, Whiteboard: [sg:spoof] seamonkey version of 271194)

Attachments

(2 files)

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.
Flags: blocking-seamonkey1.0b?
Flags: blocking-seamonkey1.0a?
Whiteboard: [sg:spoof]
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...
Attached patch Proposed patchSplinter Review
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 ;-)
Assignee: dveditz → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #202229 - Flags: superreview?(jag)
Attachment #202229 - Flags: review?(jag)
Attachment #202229 - Flags: superreview?(jag)
Attachment #202229 - Flags: superreview+
Attachment #202229 - Flags: review?(jag)
Attachment #202229 - Flags: review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
vrfy fixed: winxp, trunk, 2005110908 - urlbar is right, lock is open, www.mozilla.org is showing.
Status: RESOLVED → VERIFIED
Comment on attachment 202229 [details] [diff] [review] Proposed patch suite-only security fix.
Attachment #202229 - Flags: approval1.8rc2?
Attachment #202229 - Flags: approval1.8rc2? → approval1.8rc2+
Keywords: fixed1.8
sounds like this is fixed on branch, removing blocking nominations.
Flags: blocking-seamonkey1.0b?
Flags: blocking-seamonkey1.0a?
Flags: testcase+
Whiteboard: [sg:spoof] → [sg:spoof] seamonkey version of 271194
Group: security
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: