Closed Bug 1151916 Opened 9 years ago Closed 9 years ago

Refreshing a webpage using service worker's caches API breaks when using or caches;


(Firefox OS Graveyard :: General, defect)

Gonk (Firefox OS)
Not set


(firefox40 fixed)

Tracking Status
firefox40 --- fixed


(Reporter: salva, Assigned: nsm)




(1 file, 1 obsolete file)

0. Load the following custom prefs into Gaia
user_pref('dom.caches.enabled', true);
user_pref('dom.serviceWorkers.enabled', true);
user_pref('dom.serviceWorkers.testing.enabled', true);
user_pref('', true);

1. Tap on the search bar
2. Visit
3. Once the page is loaded, tap on the refresh button
4. Close the browser
5. Visit again
6. Once loaded, tap on refresh

The page refreshes properly.

The page crashes. If you observe the traces in adb logcat, you can see how the last trace is `Before open...`
Do you think this could be related with bug 1151892?
Flags: needinfo?(amarchesini)
I have the same STR with other app only with \caches;\ in the 'fetch' handler without opening the cache:

Code of SW:

I/Browser ( 1871): Content JS LOG: Offliner running! 
I/Browser ( 1871):     at <anonymous> (
I/Browser ( 1871): Content JS LOG: Offliner attached all listeners! 
I/Browser ( 1871):     at <anonymous> (
I/Browser ( 1871): Content JS LOG: Offliner > Fetch method 1 
I/Browser ( 1871):     at <anonymous> (
I/Gecko   ( 1122): 
I/Gecko   ( 1122): ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
I/Gecko   ( 1122): 
I/Gecko   ( 1122): ############ ErrorPage.js
I/Gecko   ( 1122): [Parent 1122] WARNING: pipe error (95): Connection reset by peer: file ../../../gecko/ipc/chromium/src/chrome/common/, line 456
I/GeckoDump( 1122): Crash reporter : Can't fetch app.reportCrashes. Exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://b2g/content/shell.js :: shell_reportCrash :: line 146"  data: no]
Same happens from Browser or when the app has been installed as trusted hosted app
Summary: Refreshing a webpage using service worker's caches API breaks when using → Refreshing a webpage using service worker's caches API breaks when using or caches;
bkelly knows more about cache. Moving the NI.
Flags: needinfo?(amarchesini) → needinfo?(bkelly)
I'm traveling at the moment and I don't have my flame with me.  I'll have to check next week.

Does this effect the desktop browser in e10s mode?
If you could get a stack trace of the crash, I could try to look at it sooner.  Sadly, I don't remember how to get a stack trace from a b2g crash.
Flags: needinfo?(salva)
Ben, I have reproduced a crash in Firefox Desktop Nightly following the steps in the description but replacing http with https in the URL that Salva posted.

I am not sure if it's exactly the same issue but just in case, it can help you. The crash report is available at:

By the way, I also have crashes in nightly using the URL included by Cristian in comment 2.
This is crashing on WorkerPrivate::GetPrincipalInfo():

Because the mInfo.mPrincipalInfo is nullptr.  This should not be possible, though, because mPrincipalInfo is always initialized in WorkerPrivate::SetPrincipal().

So it seems script is running before SetPrincipal() is called!

This is most likely fallout from bug 931249.
Depends on: 931249
Flags: needinfo?(nsm.nikhil)
Flags: needinfo?(bkelly)
Flags: needinfo?(amarchesini)
I think Maria already provided what you need. Clearing ni.
Flags: needinfo?(salva)
Assignee: nobody → nsm.nikhil
Flags: needinfo?(nsm.nikhil)
Attached file MozReview Request: bz://1151916/nsm (obsolete) —
/r/6927 - Bug 1151916 - Set worker principalinfo on cache load. r=bkelly

Pull down this commit:

hg pull -r 89f2f6e2e5d59e7a61f2b3125a286cb7d7d816eb
Attachment #8591086 - Flags: review?(bkelly)
Comment on attachment 8591086 [details]
MozReview Request: bz://1151916/nsm

r=me with the one comment address and a test case that triggers the failure.  It seems getting a cached SW to load and accessing `self.caches` is enough of a test case.

::: dom/workers/ScriptLoader.cpp
(Diff revision 1)
> +      mWorkerPrivate->SetPrincipal(principal, loadGroup);

I think maybe we should only do this in the same success case as where we call `mWorkerPrivate->SetBaseURI()` above.  I don't think we should call `SetPrincipal()` if an error occurrs.
Attachment #8591086 - Flags: review?(bkelly) → review+
Nikhil, is the test proving difficult? I'd be ok doing that in a follow-up if it means we can fix this issue soon.  I think this bug is probably making it difficult to do any SW development in Nightly Firefox right now.
Flags: needinfo?(nsm.nikhil)
Test was involved but easy, just waiting on try now.
Flags: needinfo?(nsm.nikhil)
Flags: needinfo?(amarchesini)
Closed: 9 years ago
Resolution: --- → FIXED
Depends on: 1157692
You need to log in before you can comment on or make changes to this bug.