After session restore, "Error: ASSERTION: browser.js host is inconsistent. Content window has <mochi.test:8888> but cached host is <>. Source File: chrome://browser/content/browser.js Line: 9637"

RESOLVED WORKSFORME

Status

()

Firefox
Security
--
minor
RESOLVED WORKSFORME
6 years ago
2 years ago

People

(Reporter: O. Atsushi (Torisugari), Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
This is, probably, a regression by bug 311007, and partly by bug 599909; and similar to bug 651938.

Steps to reproduce:
1. Open only one tab and enable session-restore.
2. Go to a web page, which contains few, if any, syntax errors.
   e.g. https://bugzilla.mozilla.org/
3. Close Firefox and Restart it.
4. Confirm the last page is loaded again, and launch "Error Console".

Expected Result:
No error.

Actual Result:
"Error: ASSERTION: browser.js host is ..."

I haven't anticipated sessionstore uses nsIDocShell::setCurrentURI(...) in such a way. But if they really intended to call setCurrentURI() just for the sake of calling onLocationChange() without calling onSecurityChange(), this should be fixed. Though I'm still confused... Why calling onSecurityChange() is evil, in the first place?
(In reply to O. Atsushi (Torisugari) from comment #0)
> and similar to bug 651938.

That one looks different. That's not sessionstore doing anything at that point.

> I haven't anticipated sessionstore uses nsIDocShell::setCurrentURI(...) in
> such a way. But if they really intended to call setCurrentURI() just for the
> sake of calling onLocationChange() without calling onSecurityChange(), this
> should be fixed. Though I'm still confused... Why calling onSecurityChange()
> is evil, in the first place?

That came out of bug 599909 after talking a lot with Olli (some in bug 598852, other times offline). Triggering onLocationChange was the best thing to do at the time.

I had an idea recently to make sessionstore not have to be as hacky here and make switch to tab work without faking out docshell, but that might not get too much traction. Ultimately though we wouldn't have to call setCurrentURI.
(Reporter)

Comment 2

6 years ago
(In reply to Paul O'Shannessy [:zpao] from comment #1)
> That one looks different. That's not sessionstore doing anything at that
> point.

In my opinion, Sessionstore is not doing a harmful thing, but it had been hiding this bug. I can reproduce this problem in this way:

1. Set your "Home page" a normal HTTP URI. (e.g. http://www.mozilla.org/).
2. Open a new window, from File menu.
3. Confirm home page is loaded, and look at "Error Console".

Actual and Expected results...

This problem itself is not caused by nsIDocShell::setCurrentURI(). And I don't think calling it is hacky. However, if you call onLocationChange() without onSecurityChange(), this error message will be invisible. I guess bug 651938 might be due to we are not calling onLocationChange() after initialization of the URLbar, for some reason (e.g. lack of session restore).

That's why I wonder I should fix this problem at doshell side or not.
(Reporter)

Comment 3

6 years ago
Created attachment 574597 [details] [diff] [review]
fix for this bug, comment2 and bug 651938

I believe this is more a correct solution than any others. But I feel something ridiculous in terms of performance.

And I found another bug:
1. With a debug build, create 2 bookmarks linking to
   https://support.mozilla.com/media/img/firefox-54x62.png
   and
   https://bugzilla.mozilla.org/skins/standard/global.css?1311936905
2. Push these links one after another.
3. See "Error Console".
This case seems a serious problem.
(Reporter)

Updated

6 years ago
Component: Document Navigation → Security
Product: Core → Firefox
QA Contact: docshell → firefox
(Reporter)

Comment 4

6 years ago
When docshell's onLocationChange fires onSecurityChange, browser's listener catches onSecurityChange first, then it catches onLocationChange.

docshell fires onLocationChange 
  securityUI catches onLocationChange  (from docshell)
    securityUI fires onSecurityChange
      browser catches onSecurityChange (from securityUI)
  browser catches onLocationChange     (from dochsell)

That's fair enough, for docshell registers securityUI's listener before browser's listener. On the other hand, when tabbrowser.xml fires these events, it fires onLocationChange before onSecurityChange.

So the short-circuit in browser's onSecurityChange listener is not working fine.

Updated

6 years ago
Summary: After session resotre, "Error: ASSERTION: browser.js host is inconsistent. Content window has <mochi.test:8888> but cached host is <>. Source File: chrome://browser/content/browser.js Line: 9637" → After session restore, "Error: ASSERTION: browser.js host is inconsistent. Content window has <mochi.test:8888> but cached host is <>. Source File: chrome://browser/content/browser.js Line: 9637"
Not reproduced with:
Build ID 	20151208100201
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
[devtools.errorconsole.enabled; true]
Considering this I will mark this issue as Resolved-WORKSFORME. If anyone can still reproduce it, feel free to reopen the issue and provide more information.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.