702261 - 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"

Status: RESOLVED WORKSFORME

(Firefox :: Security, defect)

Description

[O. Atsushi (Torisugari)]

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?

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(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.

Comment 2

[O. Atsushi (Torisugari)]

(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.

Comment 3

[O. Atsushi (Torisugari)]

Attachment: 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.

Comment 4

[O. Atsushi (Torisugari)]

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.

Comment 5

[Michelle Funches - QA]

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.