The default bug view has changed. See this FAQ.

Apps cannot operate offline right now - Offline cache cannot be used

VERIFIED FIXED in Firefox 15

Status

Firefox Graveyard
Webapp Runtime
P1
critical
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: jsmith, Assigned: myk)

Tracking

(Blocks: 1 bug)

unspecified
Firefox 15
Dependency tree / graph

Details

(Whiteboard: [topapps], [blocking-webrtdesktop1+], [appreview-blocker], [qa!])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Steps:

1. Install an app that uses offline cache
2. Make sure offline cache gets populated while using the application
3. Turn off your internet connection
4. Continue using the application

Expected:

The application parts that utilize offline cache should still continue to work without an internet connection.

Actual:

Offline cache was not read - Connection failures get thrown (connection reset while page was loading, could not connect).

Example scenario to test this with a real app:

1. Install lanyrd mobile (https://marketplace.mozilla.org/en-US/app/lanyrd-mobile/?src=search)
2. Login with a twitter account
3. Look at your events
4. Shut off the internet connection
5. Try using the application
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta?]
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta?]
(Reporter)

Updated

5 years ago
Whiteboard: [topapps]
(Reporter)

Comment 1

5 years ago
Created attachment 618484 [details]
Lanyrd Mobile Example
(Reporter)

Updated

5 years ago
blocking-kilimanjaro: --- → ?
Whiteboard: [topapps] → [topapps], [marketplace-beta-]
(Reporter)

Updated

5 years ago
Keywords: qawanted
(Reporter)

Updated

5 years ago
Blocks: 737571

Updated

5 years ago
blocking-kilimanjaro: ? → +
(Reporter)

Updated

5 years ago
No longer blocks: 737571
(Reporter)

Updated

5 years ago
Whiteboard: [topapps], [marketplace-beta-] → [topapps]
(Reporter)

Updated

5 years ago
Duplicate of this bug: 754320
(Reporter)

Comment 3

5 years ago
Andy and I have both confirmed this be a problem (see the bug this is a duped against, bug 754320 for an example). This is a big problem - We're advertising this in our product vision, but we apparently aren't supporting offline mode.
Keywords: qawanted
(Reporter)

Comment 4

5 years ago
Flagging uiwanted - we need a user interface to prompt the user to allow the app to store data for offline use.
Keywords: uiwanted
UX recommendation is to use the native notification system. 

UX will put a mock up in this bug to show this.

Engineering needs to estimate the work for this.

Comment 6

5 years ago
Why are we asking permission to use applicationCache? Permission should be implicit for an app a users installs. (Fairly certain this is the case on b2g)
(Reporter)

Comment 7

5 years ago
(In reply to Potch [:potch] from comment #6)
> Why are we asking permission to use applicationCache? Permission should be
> implicit for an app a users installs. (Fairly certain this is the case on
> b2g)

True (https://wiki.mozilla.org/Apps/Security/Permissions). Desktop firefox currently does prompt the user to do this, so it's likely it's being implemented incorrectly there as well given this specification. We could either fix the problem in the core (better long term route), or work around the issue in the short-term in the front-end based on how firefox does it (although I'm against using short-term hacks unless it's absolutely necessary).

Jonas - Thoughts? Should we resolve this problem in the underlying core?
In the context of apps we should definitely not be asking for permission to use the appcache. This will be handled once we implement the automatic downloading of appcache resources during application install, which I don't think has been implemented yet.
(Reporter)

Comment 9

5 years ago
(In reply to Jonas Sicking (:sicking) from comment #8)
> In the context of apps we should definitely not be asking for permission to
> use the appcache. This will be handled once we implement the automatic
> downloading of appcache resources during application install, which I don't
> think has been implemented yet.

Gotcha. Sounds like bug 752705. Should we duplicate this bug against that one, since they target the same underlying problem? Or is this bug depend on the implementation of bug 752705?
(Reporter)

Comment 10

5 years ago
Actually, I'll mark this is a depending on that bug (I think that makes more sense), unless there's disagreement on that.
Depends on: 752705
(Reporter)

Comment 11

5 years ago
FYI to Brian Dils - We no longer need a UI for this.
Keywords: uiwanted
(Reporter)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
No longer depends on: 752705
Resolution: --- → DUPLICATE
Duplicate of bug: 752705
(Reporter)

Updated

5 years ago
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Updated

5 years ago
Priority: -- → P1
Whiteboard: [topapps] → [topapps], [blocking-webrtdesktop1+]
Target Milestone: --- → M1
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
(Reporter)

Updated

5 years ago
Target Milestone: M1 → Firefox 15
Blocks: 746388
(Reporter)

Updated

5 years ago
Whiteboard: [topapps], [blocking-webrtdesktop1+] → [topapps], [blocking-webrtdesktop1+], [appreview-blocker]
(Assignee)

Comment 13

5 years ago
Jonas, Honza: in case the appcache changes don't land in time for Firefox 15, is there a fix we can land for just this bug?
As I understand, you lack "offline-app" permission being set to ALLOW for an app's domain.  I don't think I'm the right person to ask anything to do about that in particular, but it is fairly easy to do IMO.

If this is blocked on bug 756620, then my part (allow of preload from the firefox process, bug 753990) is mostly done - a green-try patch is waiting for second review from Michal.

Olli's bug 756131 has already been landed.
If I understand Jonas correctly, this bug is subsumed by the work associated with bug 756620?
No, this bug is also needed for bug 756620. Even with the appcache loaded during install, the webapp still needs its permission set to use it.

I believe that what is needed here is just to call Services.perms.addPermission in webapp.js before the app URL is loaded, but I don't know if there are other settings that need to be configured to allow appcache to work  (e.g. what controls the max cache size? is it a fixed value or something that needs to be set)
Blocks: 756620
(Assignee)

Updated

5 years ago
Assignee: nobody → myk
Status: REOPENED → ASSIGNED
(In reply to Felipe Gomes (:felipe) from comment #16)
> I believe that what is needed here is just to call
> Services.perms.addPermission in webapp.js before the app URL is loaded

Yes.  Or on some other place, or it can be set as part of the preload process by Firefox.

> , but
> I don't know if there are other settings that need to be configured to allow
> appcache to work  (e.g. what controls the max cache size? is it a fixed
> value or something that needs to be set)

There is a default value for this and AFAIK it is 512MB.
(Assignee)

Updated

5 years ago
OS: Windows 7 → All
Hardware: x86_64 → All
(Assignee)

Comment 18

5 years ago
Created attachment 628150 [details] [diff] [review]
work in progress

Something like this should work, but I haven't tested it yet.
(Assignee)

Comment 19

5 years ago
Created attachment 628395 [details] [diff] [review]
patch v1: set appcache permissions appropriately

Here's a patch that sets the appropriate permissions for the app to be able to use appcache.  According to Jonas, the permissions are pin-app and offline-app.

Ideally, we'd do this at installation time.  But that would require creating the profile on installation and training the permissions manager to set permissions in it.  So this patch sets the permissions on firstrun, which is also when the platform creates the profile.

Tested with the Lanyrd app, which successfully cached events I tracked and showed me information about them (including information I had never looked at) when I went offline after installing and running the app using a version of Firefox built with this patch.  I also confirmed that the appropriate permissions are set in permissions.sqlite within the app's profile directory (and that webapprt.firstrun is set appropriately in the profile's prefs.js file).
Attachment #628150 - Attachment is obsolete: true
Attachment #628395 - Flags: review?(felipc)
Comment on attachment 628395 [details] [diff] [review]
patch v1: set appcache permissions appropriately

Review of attachment 628395 [details] [diff] [review]:
-----------------------------------------------------------------

::: webapprt/CommandLineHandler.js
@@ +56,5 @@
> +
> +    // Now that we've set the appropriate permissions, twiddle the firstrun flag
> +    // so we don't try to do so again.
> +    Services.prefs.setBoolPref("webapprt.firstrun", true);
> +  }

Hmm except for the Webapps.jsm import which might need to happen super early in this component (or not, but we don't need to experiment changing it here), I believe that all the start-up code being added could happen in the global scope of webapp.js, and that would feel less hackish than adding it here in the the component code..
or is there a reason you thought about that webapp.js wouldn't work?
(Assignee)

Comment 21

5 years ago
(In reply to Felipe Gomes (:felipe) from comment #20)
> Hmm except for the Webapps.jsm import which might need to happen super early
> in this component (or not, but we don't need to experiment changing it
> here), I believe that all the start-up code being added could happen in the
> global scope of webapp.js, and that would feel less hackish than adding it
> here in the the component code..
> or is there a reason you thought about that webapp.js wouldn't work?

To my mind, they're equally hackish, as neither context is intended for such work.

Ideally, there'd be platform support for registering code that should be executed on firstrun.  Failing that, the code might be better off in an XPCOM component that registers with the category manager for instantiation on startup.  Except that it isn't reusable by the rest of the codebase the way other XPCOM components are, so it doesn't fit the usecases for which XPCOM is intended either.  And it's Yet Another XPCOM Component (YAXC), instead of Yay One Less XPCOM Component (YOLXC)!

I chose CommandLineHandler because we're already using it to do startup work unrelated to command-line handling (initializing the webapp registry by importing Webapps.jsm), and because startup work done in CommandLineHandler will certainly happen before the app is loaded, which needs to happen in this case.

But that latter constraint can be satisfied in webapp.js as well, so it's an option, and I'm open to it.
Comment on attachment 628395 [details] [diff] [review]
patch v1: set appcache permissions appropriately

Ok sounds good, we can always revisit this later if needed. I pointed Drew to take a look here at this bug since he is also changing where Webapps.jsm gets loaded in bug 733631.
Attachment #628395 - Flags: review?(felipc) → review+
(Assignee)

Comment 23

5 years ago
Comment on attachment 628395 [details] [diff] [review]
patch v1: set appcache permissions appropriately

https://hg.mozilla.org/integration/mozilla-inbound/rev/4b6e98c0317b
Attachment #628395 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/4b6e98c0317b
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
(Reporter)

Updated

5 years ago
Whiteboard: [topapps], [blocking-webrtdesktop1+], [appreview-blocker] → [topapps], [blocking-webrtdesktop1+], [appreview-blocker], [qa+]
(Reporter)

Updated

5 years ago
Whiteboard: [topapps], [blocking-webrtdesktop1+], [appreview-blocker], [qa+] → [topapps], [blocking-webrtdesktop1+], [appreview-blocker], [qa+:jsmith]
(Reporter)

Comment 25

5 years ago
Tested with At Work - offline mode did work. Would prefer to also test lanyrd mobile (as that's the better test here to really see if this works), but I'm blocked by bug 752666 not landing. Will verify with lanyrd mobile once bug 752666 lands.
(Reporter)

Updated

5 years ago
Flags: in-moztrap?(jsmith)
(Reporter)

Updated

5 years ago
Status: RESOLVED → VERIFIED
Whiteboard: [topapps], [blocking-webrtdesktop1+], [appreview-blocker], [qa+:jsmith] → [topapps], [blocking-webrtdesktop1+], [appreview-blocker], [qa!]
(Reporter)

Comment 26

5 years ago
Created attachment 633582 [details]
Stuck on WebRT vs. Desktop Firefox Having Prompt
(Reporter)

Comment 27

5 years ago
Well, thought this was fixed, but upon doing crash testing on the web runtime, I just found out it isn't fixed in every possible case :(. See attached screenshot. Basically I loaded https://touch.betfair.com/ in the desktop web runtime. As you can see by the screenshot, the runtime is stuck, likely waiting for a user response to a prompt that does not exist to enable offline cache. Although in the runtime's case, this prompt should have never happened in the first place given the above approach suggested in the above comments. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
this may be a indexedDB prompt, not an offline-cache prompt. You need to set a different permission for that.
(Reporter)

Comment 29

5 years ago
(In reply to Fabrice Desré [:fabrice] from comment #28)
> this may be a indexedDB prompt, not an offline-cache prompt. You need to set
> a different permission for that.

Ah, sounds like bug 757678 then. I'll close this then and make a comment in that bug. Thanks for the input on this.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
(Reporter)

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Updated

5 years ago
QA Contact: desktop-runtime → jsmith
(Reporter)

Updated

5 years ago
Flags: in-moztrap?(jsmith)
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.