Closed Bug 462863 Opened 16 years ago Closed 16 years ago

about:sessionrestore shouldn't display authentication requests for favicons

Categories

(Firefox :: Session Restore, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: tonikitoo, Assigned: zeniko)

References

Details

(Keywords: verified1.9.1)

Attachments

(2 files)

Attached image bug sshot. (deleted) —
1) Go to a website that requires a prompt login (user/passwd). e.g. https://projects.maemo.org/homepage was my testcase. I will post a generic testcase soon. 2) Log in. 3) Force browser to close abruptly (similate a crash). 4) Restart browser. 5) New session recover webpage shows up. Actual outcome: User/passwd dialog from testcase should not pop up until user mark that webpage to be recovered in the list.
Summary: SessionRestore tries should not pre-fetch websites that require dialog authentication until session is effectively restored. → SessionRestore should not pre-fetch websites that require dialog authentication until session is effectively restored.
Summary: SessionRestore should not pre-fetch websites that require dialog authentication until session is effectively restored. → about:sessionrestore shouldn't display authentication requests for favicons
Attachment #346938 - Flags: review?(dietrich)
Attachment #346938 - Flags: review?(dietrich) → review-
Comment on attachment 346938 [details] [diff] [review] get favicons over moz-anno:favicon: nope. http auth can be challenged via http instead of https. i can setup a server if you need one.
Comment on attachment 346938 [details] [diff] [review] get favicons over moz-anno:favicon: (In reply to comment #3) > nope. http auth can be challenged via http instead of https. So? Have you actually tried the patch?
Attachment #346938 - Flags: review- → review?(dietrich)
Blocks: 466900
As said by Simon this patch should also fix bug 466900. Because it is All/All this one should have the same flags. Dietrich, do you have time to review the patch?
Assignee: nobody → zeniko
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Comment on attachment 346938 [details] [diff] [review] get favicons over moz-anno:favicon: r=me
Attachment #346938 - Flags: review?(dietrich) → review+
Keywords: checkin-needed
Attachment #346938 - Flags: approval1.9.1?
should set checkin-needed only after approval is granted
Keywords: checkin-needed
(In reply to comment #7) > should set checkin-needed only after approval is granted Aren't we supposed to bake our patches on Trunk first (where no approval is needed)?
Keywords: checkin-needed
(In reply to comment #8) > Aren't we supposed to bake our patches on Trunk first (where no approval is > needed)? Yes, and it would be great to have it in mozilla-central so we can check if it really fixes bug 466900.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Asking for blocking1.9.1 because it will also fix bug 466900 for Fx3.1
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Attachment #346938 - Flags: approval1.9.1?
Keywords: checkin-needed
Verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081224 Shiretoko/3.1b3pre ID:20081224020421 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081222 Minefield/3.2a1pre ID:20081222020443 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081224 Shiretoko/3.1b3pre ID:20081224042714 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081224 Minefield/3.2a1pre ID:20081224034752
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: