Listing indexedDB from a javascript: iframe fails with TypeError

RESOLVED FIXED in Firefox 48

Status

defect
P1
normal
RESOLVED FIXED
3 years ago
11 months ago

People

(Reporter: jsnajdr, Assigned: timhuang)

Tracking

Trunk
Firefox 48
Dependency tree / graph

Firefox Tracking Flags

(firefox48 fixed)

Details

(Whiteboard: [OA])

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

3 years ago
Steps to reproduce:
1. Load the patch from bug 1262766 and run the devtools/client/storage/test/browser_storage_cache_error.js mochitest.

Expected result:
It passes.

Actual result:
After bug 1237915 has landed, initializing the Storage Inspector fails on this test's test page (storage-cache-error.html) with a TypeError:

Full message: TypeError: win is null
Full stack: .populateStoresForHost<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/storage.js:1615:9

This is caused by the iframe with the "javascript:parent.frameContent" URL. The getWindowFromHost method searches for the right window by comparing the host to:

win.document.nodePrincipal.originNoSuffix

The origin however is "http://test.example.org", not the javascript: URL, so nothing is found and null is returned. The calling code doesn't expect the return value to be null.

On the other hand, the win.location.href contains the right javascript: URL (and win.location.origin is null).

I have no idea now all that principal magic work and I'm unable to fix this myself.
Reporter

Updated

3 years ago
Blocks: 1262766
See Also: → 1237915
Assignee

Comment 1

3 years ago
When a new window has been created, the storage actor is going to know this new window through the observer event 'content-document-global-created' [1]. Then, the getWindowFromHost can acquire this window correctly.

However, it seems like that this observer event does not happen after the creation of the iframe in storage-cache-error.html. I think it causes this problem. But I really don't know why this event does not occur. 

[1] https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/storage.js#2208
Reporter

Comment 2

3 years ago
(In reply to Tim Huang[:timhuang] from comment #1)
> However, it seems like that this observer event does not happen after the
> creation of the iframe in storage-cache-error.html. I think it causes this
> problem. But I really don't know why this event does not occur. 

This is true only for windows created after the Storage Inspector is initialized and running. When the storage inspector is starting up, it fetches the windows in the fetchChildWindows method [1]. This is what happens in the cache-error test.

When the getWindowFromHost method can't find the window, it's not because it's missing from this.childWindowPool. It's there. It's not found because the comparison in [2] doesn't find it. "host" is the javascript: URL, but the "origin" (fetched from the principal) is the URL of the site, http://test1.example.org.

[1] https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/storage.js#2147-2165
[2] https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/storage.js#2189
Assignee

Comment 3

3 years ago
I think the window of the site 'http://test1.example.org' belongs to the tab window. The function fetchChildWindows will add tab window into the childWindowPool as well as other child windows. So, if it works correctly, the window pool should contain two windows, one for 'http://test1.example.org' and another for 'javascript: URL' for this test case. But now, it only has the tab window, the site of 'http://test1.example.org'.
Reporter

Comment 4

3 years ago
(In reply to Tim Huang[:timhuang] from comment #3)
> But now, it only has the tab window, the site of 'http://test1.example.org'.

When I run the test locally, both windows are there, but the javascript: one fails to be found. If I add the following log statement before line [1]:

console.log(`Searching for window ${host}, checking origin=${origin}`, win.location);

and run the cache-error test, I get this:

console.log: Searching for window javascript:parent.frameContent, checking origin=http://test1.example.org Location {
  "href":"http://test1.example.org/browser/devtools/client/storage/test/storage-cache-error.html",
  "origin":"http://test1.example.org",
  "protocol":"http:",
  "host":"test1.example.org",
  "hostname":"test1.example.org",
  "port":"",
  "pathname":"/browser/devtools/client/storage/test/storage-cache-error.html",
  "search":"",
  "hash":""
}
console.log: Searching for window javascript:parent.frameContent, checking origin=http://test1.example.org Location {
  "href":"javascript:parent.frameContent",
  "origin":"null",
  "protocol":"javascript:",
  "host":"",
  "hostname":"",
  "port":"",
  "pathname":"",
  "search":"",
  "hash":""
}

Both windows are there, origin from principal is the same, the javascript: URL is only in the win.location.href.

[1] https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/storage.js#2189
Whiteboard: [OA]
Assignee

Updated

3 years ago
Assignee: nobody → tihuang
Status: NEW → ASSIGNED
Reporter

Comment 5

3 years ago
A very similar issue happens in bug 1215349, on the about:home page. On this page, indexedDBs are not shown, although the page has an "abouthome" database. This happens because the getWindowFromHost fails to find the window. The origin from the principal is "moz-safe-about:home", the "host" is just "about:home".
See Also: → 1215349
Assignee

Comment 6

3 years ago
This patch makes the getWindowFromHost not only checks the origin, but also checks the url of the document with the host.
Attachment #8740955 - Flags: review?(mratcliffe)
Attachment #8740955 - Flags: review?(mratcliffe) → review+
Assignee

Comment 7

3 years ago
Rebase mozilla-central.
Attachment #8742005 - Flags: review+
Assignee

Updated

3 years ago
Attachment #8740955 - Attachment is obsolete: true
Assignee

Updated

3 years ago
Keywords: checkin-needed

Comment 10

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/8997f9366f6b
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48

Updated

11 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.