Closed Bug 767807 Opened 12 years ago Closed 12 years ago

The web app runtime gets hung when it is off the app origin and requesting app cache use

Categories

(Firefox Graveyard :: Webapp Runtime, defect)

Product:
Firefox Graveyard
Component:
Webapp Runtime
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-kilimanjaro:+, firefox16-)

Status:
RESOLVED INVALID
Milestone:
Firefox 16
Project Flags:
blocking-kilimanjaro +
Tracking Flags:
Tracking Status
firefox16 - ---

People

(Reporter: jsmith, Unassigned)

References

Details

The web app runtime appears to get stuck when loading URLs that would normally cause the app cache prompt to appear such as what's below:

This website (www.example.com) is asking to store data on your computer for offline use. [Allow] [Never for This Site] [Not Now]

Reference: https://developer.mozilla.org/en/Offline_resources_in_Firefox

Example test case:

1. Load touch.betfair.com

Result - The web app runtime gets stuck in the loading state. In desktop firefox, you would normally see the offline cache prompt above.

Note that if you were even successful getting past that prompt, you would still end up crashing right now due to bug 760955's existence. An example crash report with that bug is:

https://crash-stats.mozilla.com/report/index/bp-0b511fa4-f234-4d9e-bbec-26fbd2120624
k9o nomination - we are strongly encouraging use of app cache with web apps (very highly likely use case). Ending up in a scenario where an app can't finish loading when using app cache is a bad user experience and can even risk discouraging app developers from not using it.
blocking-kilimanjaro: --- → ?
blocking-kilimanjaro: ? → +
Blocks: 757678
Priority: -- → P1
Whiteboard: [blocking-webrtdesktop1+]
Can someone take this bug? We're blocking on the 1st release for this.
tracking-firefox16: --- → ?
Let me take a look at this
Assignee: nobody → felipc
Lucas - If an app goes off of its origin, and the off-origin content requests access to appcache, what permissions rules do we follow? Prompt for allow or not allow? Deny the appcache permission all-together? Something else all-together?

The above bug being hit here is that if an app goes to a different origin than the origin of the app and app cache is requested, we get hung (we don't have a way to handle this right now).
QA Contact: jsmith
Summary: The web app runtime gets stuck loading on places where a website in Firefox causes an app cache prompt to appear → The web app runtime gets hung when it is off the app origin and requesting app cache use
Note that this is blocking because it hangs the runtime, and we must resolve that one way or the other, so it isn't possible for a site from another origin to hang an app just because the app navigates to it.

So arbitrarily denying appcache access to other-origin sites (or arbitrarily permitting such access, for that matter) would be sufficient to resolve the blocking issue, and we must do something like that if we can't come up with a better solution.
Unlike a browser I don't think the user expects to encounter random cross-domain permission prompts inside an app, so lets take that off the table.  Their relationship is with the app and they expect the app to be responsible for managing local data storage.

Always deny is probably the best approach for us unless we figure out a neater approach.
Code references to the browser.offline-apps.notify preference suggest that setting it to false will prevent a browser from prompting, but that behavior is built into browser-specific observers of MozApplicationManifest events, including those of Firefox (which sets it to true), Fennec (true), and B2G (false); it isn't handled by the platform.

And in my testing I don't see the behavior described here, so it isn't clear that it is even necessary to set that pref (or do anything else, for that matter).

To test, I created a web page that uses a manifest to cache two files, the page itself (although it is already implicitly cached due to its <html> tag's `manifest` attribute) and one other HTML file:

Page that uses a manifest: https://people.mozilla.com/~myk/apps/index.html
Other page that is cached: https://people.mozilla.com/~myk/apps/test.html

I then linked to that web page from Mykzilla:

http://www.mykzilla.org/app/

When I load Mykzilla in a browser tab and click its App Cacher link, the browser correctly prompts me to approve people.mozilla.com's permission to store data on my computer for offline use.

And when I load Mykzilla as an app and click its App Cacher link, Mykzilla correctly does *not* prompt me to approve that permission.  But neither does it "hang" in any sense of the word.  To the contrary, both its chrome and its content continue to work just fine.  I can access chrome menuitems, and I can interact with the content.

In fact, I added a button to the page to tell me the status of the appcache, and it correctly reports that the page is UNCACHED.  I also added a button that returns me to Mykzilla, and it works fine as well.

So it isn't clear what the problem is here, but there doesn't seem to be any kind of hang.  Perhaps it's just that the page in question requires the cache to load.  If so, that seems unfortunate, but also not an issue that we can resolve in the runtime, provided we maintain the policy Lucas outlined in comment 6 that only the app's origin can use the appcache.

But note that B2G allows all origins to use the appcache by default <http://hg.mozilla.org/mozilla-central/file/340764f48ed2/b2g/app/b2g.js#l31>.  Perhaps the runtime should do the same?
Assignee: felipc → myk
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 16
(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> So it isn't clear what the problem is here, but there doesn't seem to be any
> kind of hang.  Perhaps it's just that the page in question requires the
> cache to load.  If so, that seems unfortunate, but also not an issue that we
> can resolve in the runtime, provided we maintain the policy Lucas outlined
> in comment 6 that only the app's origin can use the appcache.

That's likely what's going on with the site in comment 0. So the bug here does not block access to all content. Instead, it blocks continuation of the area of code that is after when the appcache prompt appears. So whatever follows that probably never occurs, which can include content, if the site operates that way.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> But note that B2G allows all origins to use the appcache by default
> <http://hg.mozilla.org/mozilla-central/file/340764f48ed2/b2g/app/b2g.js#l31>.
> Perhaps the runtime should do the same?

Lucas what do you think?
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> > But note that B2G allows all origins to use the appcache by default
> > <http://hg.mozilla.org/mozilla-central/file/340764f48ed2/b2g/app/b2g.js#l31>.
> > Perhaps the runtime should do the same?
> 
> Lucas what do you think?

Hmm that seems strange.  Let me ping Jonas to see if he has any insights.
(In reply to Jason Smith [:jsmith] from comment #8)
> That's likely what's going on with the site in comment 0. So the bug here
> does not block access to all content. Instead, it blocks continuation of the
> area of code that is after when the appcache prompt appears. So whatever
> follows that probably never occurs, which can include content, if the site
> operates that way.

The appcache prompt is triggered declaratively and asynchronously via a `manifest` attribute on the <html> tag of the web page, so its absence doesn't block any code from executing.

Its absence might mean that some appcache-related event, for which the site is listening, doesn't get dispatched.  But that's no different from the user pressing the "Never for this site" or "Not now" buttons in the prompt, and when I press one of those buttons in the browser, I see the same behavior on the site as I see in the runtime: nothing more happens.

So the problem here is in the design of the website.  The runtime works as expected.  However, I'll leave this bug open while considering whether we to change the behavior of appcache to permit all sites to use it by default.
Marking for re-triage - the above comments seem to imply that this has a low likelihood of being hit based on the design of the site.
Priority: P1 → --
Whiteboard: [blocking-webrtdesktop1+]
It's not so much that it has a low likelihood of happening as that the thing that can happen is an issue in the website rather than an issue in the runtime.  The runtime behaves as intended.

There is still some question about whether the behavior in the runtime is optimal, especially given that B2G implements different behavior.  But Bill pointed out during triage today that this issue and that one are different and separable, so we should separate them.

Thus I am resolving this bug and will raise that issue in a different forum.
Assignee: myk → nobody
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
(In reply to Lucas Adamski from comment #9)
> > (In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> > > But note that B2G allows all origins to use the appcache by default
> > > <http://hg.mozilla.org/mozilla-central/file/340764f48ed2/b2g/app/b2g.js#l31>.
> > > Perhaps the runtime should do the same?
> > 
> > Lucas what do you think?
> 
> Hmm that seems strange.  Let me ping Jonas to see if he has any insights.

Lucas subsequently filed B2G bug 773055 on this issue.
I'm not suggesting we re-open this but since touch.betfair.com is still broken can we assign this to "Evangelism" and have one of the team contact the site admin?
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.