Closed
Bug 1362346
Opened 7 years ago
Closed 7 years ago
HTTP favicons are saved in bookmarks on HTTPS website pages
Categories
(Toolkit :: Places, defect)
Tracking
()
VERIFIED
WONTFIX
Tracking | Status | |
---|---|---|
firefox-esr45 | --- | unaffected |
firefox-esr52 | --- | unaffected |
firefox53 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | wontfix |
People
(Reporter: Virtual, Unassigned)
References
Details
(Keywords: nightly-community, regression, reproducible)
Attachments
(2 files)
STR. 1. Open these website pages: - http://sessionmanager.mozdev.org/ - https://sessionmanager.mozdev.org/ 2. Bookmark them all 3. See that no favicon was saved in HTTPS bookmark, as that website page doesn't have one 4. Restart Firefox to see that HTTP favicon is added to HTTPS bookmark which doesn't have any favicon This breaks rule, which was described in Bug #1359466 Comment #2 by Marco Bonardo [::mak] > All the urls in comment 0 are trying to serve an unsecure > favicon while they are https, this is not allowed by our security checks. Tested with Mozilla Firefox Nightly 55.0a1 (2017-05-04) (64-bit) [Portable] with clean new fresh profile without any addons (extensions, plugins, themes, etc.) Works fine with Mozilla Firefox 54 Beta 3 (64-bit) [Portable] with clean new fresh profile without any addons (extensions, plugins, themes, etc.) [Tracking Requested - why for this release]: Regression "Speedy" Regression window (mozilla-central) Good: https://ftp.mozilla.org/pub/firefox/nightly/2017/04/2017-04-12-03-02-52-mozilla-central/ Bad: https://ftp.mozilla.org/pub/firefox/nightly/2017/04/2017-04-13-03-02-27-mozilla-central/ Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40e24f40b4c4556944c762d4764eace261297f5&tochange=819a666afddc804b6099ee1b3cff3a0fdf35ec15 Probably caused by: d73a295b3652 Marco Bonardo — Bug 977177 - Invalidate the page-icon image cache when necessary. r=adw 42df4b3da073 Marco Bonardo — Bug 977177 - Don't expire root domain icons with history, and don't associate pages to them. r=adw 5311e5ac3b4b Marco Bonardo — Bug 977177 - Add favicons.sqlite to profile related lists. r=adw,jmaher 864e72c60156 Marco Bonardo — Bug 977177 - Split ico files into native frames. r=adw 62f3fc3cb351 Marco Bonardo — bug 977177 - Fallback to the root domain icon. r=adw 60002894a42b Marco Bonardo — Bug 977177 - Expire old page to icon relations to avoid serving deprecated icons. r=adw 4a0770d810dc Marco Bonardo — Bug 977177 - Add size ref fragment to icon protocols. r=adw 90d755bcbb92 Marco Bonardo — Bug 977177 - Update favicons API consumers. r=adw 942aa1533e08 Marco Bonardo — Bug 977177 - Move favicons to a separate store. r=adw
Flags: needinfo?(mak77)
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•7 years ago
|
Has Regression Range: --- → yes
Has STR: --- → yes
Comment 3•7 years ago
|
||
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #0) > This breaks rule, which was described in Bug #1359466 Comment #2 by Marco > Bonardo [::mak] > > All the urls in comment 0 are trying to serve an unsecure > > favicon while they are https, this is not allowed by our security checks. it's slightly different and more complicated than that. If the https serves an http icon, we cannot download it, because of security concerns, so we can't associate the icon. BUT, if we *already* have the http icon because it was downloaded from a previous visit to the unsecure page, there's no reason to not use it, it's local already. This is valid for what we call root domain icons, in this case http://sessionmanager.mozdev.org/favicon.ico.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mak77)
Resolution: --- → WONTFIX
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 4•7 years ago
|
||
(In reply to Marco Bonardo [::mak] from comment #3) > if we *already* have the http icon because it was downloaded from a > previous visit to the unsecure page, there's no reason to not use it, it's > local already. Seems logical.
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•7 years ago
|
QA Contact: Virtual
You need to log in
before you can comment on or make changes to this bug.
Description
•