Closed Bug 1234021 Opened 7 years ago Closed 6 years ago
With "Accept cookies from sites" unchecked, history of back/forward buttons fails with "Error: Security
Error: The operation is insecure ." in Session Storage .jsm
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20151210085006 Steps to reproduce: 1) open a new empty tab, or "open link in new tab" the following URL (this didn't happen when there's another site before it in tab history): 2) visit http://www.openxcom.com/ 3) follow a link within the site, e.g. "mods" 4) right click on "Back" or "Forward" button Whether NoScript is set to allow or deny does not matter, and the bug happens even when FF is started in Safe Mode. Same happens with http://lparchive.org/X-COM-UFO-Defense/ - but not in Safe Mode, though NoScript status still doesn't matter. This also doesn't happen when current or previous URL is HTTPS (though this may cause another bug, with History menu being obviously incorrect). Actual results: - nothing visible tab history menu does not appear - console logs error: Timestamp: ... Error: SecurityError: The operation is insecure. Source File: resource://app/modules/sessionstore/SessionStorage.jsm Line: 148 Expected results: context menu: tab history should pop up, like in any other tab.
Severity: normal → minor
Component: Untriaged → Security
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
I was not sure - it was sessionstore, but it throws SecurityError when calling something. Anyway, it appears on different sites, but not every other, and repeatability varies by site. Like with lparchive.org being immune in Safe Mode, but affected in my normal setup (even though there are no unusual settings for it - no greasemonkey scripts, nothing, just one more site with cookies and scripts denied by default). Sometimes the bug disappears in some tab after some browsing around even on an affected site, but appears again in a new tab with the same site. Aw, forgot to add ufopaedia.org to the list. =) Also, it doesn't seem to matter whether an immune URL is in back or forward part of the history - it was enough to visit "about:mozilla" and go back to make history menu work in an affected tab.
STR: 1) Uncheck the option "Accept cookies from sites" 2) Open a new tab and load http://www.openxcom.com/ 3) Click on a menu entry like "MODS" 4) Right-click on back button to display history Result: No context menu with 2 entries like http://i.imgur.com/YoJtoLb.jpg for back button. Same for forward button. Error: SecurityError: The operation is insecure. Source File: resource://app/modules/sessionstore/SessionStorage.jsm Line: 148 Reg range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cadeefe3e92791a426c3e950b78e4a38a7093e9a&tochange=1056ac371c0468cde5600a7c5765dc170c5f77e5 Bobby Holley — Bug 1201747 - Don't inspect the subject principal in StorageAllowedForPrincipal. r=mystor
Status: UNCONFIRMED → NEW
Component: Session Restore → DOM: Service Workers
Ever confirmed: true
Flags: needinfo?(turbobeholder) → needinfo?(bobbyholley)
Product: Firefox → Core
Summary: [byzantine] tab history menu fails with SecurityError → With "Accept cookies from sites" unchecked, history of back/forward buttons fails with "Error: SecurityError: The operation is insecure." in SessionStorage.jsm
Bug 1201747 was just fixing a mistake in bug 1184973, so given the regression range, that's the real culprit here.
Flags: needinfo?(bobbyholley) → needinfo?(michael)
I think I've figured out what's causing this - discussing potential solutions in bug 1245595.
Recent regression (from 43), tracking.
Still happens in FF 44.0 now. (In reply to Elhem Enohpi from comment #2) > And to confirm, you have cookies disabled for these sites? That agrees with > my testing. I just tested, you're right. It depends on cookies - switching Cookie Controller settings to "Accept" or "Accept for a session" makes an affected tab's history work normally after the next click on a link (same host).
This is a simple fix which I believe should fix the problem, and be small enough to be safe to uplift. We still want to find the desired behavior in bug 1245595 for nightly & future releases. (mconley: I'm not sure if you're the right person to r? on this, but I figure you'll know who to redirect to) try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9ebe80820005
Attachment #8717741 - Flags: review?(mconley)
Attachment #8717741 - Flags: review?(mconley) → review+
I'm so sorry for the delay on this - I thought I had posted this ages ago, but then I realized I hadn't :S
Attachment #8723337 - Flags: review?(mconley)
Attachment #8717741 - Attachment is obsolete: true
Comment on attachment 8723337 [details] [diff] [review] Catch exceptions raised by storage.length in SessionStorage.jsm Review of attachment 8723337 [details] [diff] [review]: ----------------------------------------------------------------- If you can confirm that this test fails without your patch, then LGTM.
Attachment #8723337 - Flags: review?(mconley) → review+
Comment on attachment 8723337 [details] [diff] [review] Catch exceptions raised by storage.length in SessionStorage.jsm Approval Request Comment [Feature/regressing bug #]: Bug 1201747 [User impact if declined]: Comment 0 [Describe test coverage new/current, TreeHerder]: Has automated tests [Risks and why]: Should be pretty safe [String/UUID change made/needed]: None.
This should probably land on m-c first before uplift. We are also pretty late in the beta cycle so this may not make 45. Aurora uplift should be fine.
Is bug 1230769 related to this?
(In reply to xuu from comment #20) > Is bug 1230769 related to this? Yes, I believe that this patch should fix that problem.
Comment on attachment 8723337 [details] [diff] [review] Catch exceptions raised by storage.length in SessionStorage.jsm This is too late in the 45 cycle as we are now doing RC. We already shipped 44 with it. But taking it in 46.
Duplicate of this bug: 1232955
You need to log in before you can comment on or make changes to this bug.