1168777 - remove mozIApplicationClearPrivateDataParams

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect, P2)

Description

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

see https://bugzilla.mozilla.org/show_bug.cgi?id=1168300#c6

Comment 1

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

per Jonas' comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1168300#c8,
this will be 'remove webapps-clear-data notification'
I'll update the bug subject later once the picture gets more clear.

Comment 2

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Hi Jonas and Bobby
I found some components will use the appId in mozIApplicationClearPrivateDataParams to get the manifestURL, like dom/simplepush/PushService.jsm, AlarmService.jsm, InterAppCommService.jsm.

Will we change/replace 'manifestURL' in new security model?
For example will AppService cannot get the manifestURL for the signed content, or the signed content will run multiple instances and they share the same manifestURL?

Thanks

Comment 3

[Bobby Holley (:bholley)]

(In reply to Yoshi Huang[:allstars.chh] from comment #2)
> Hi Jonas and Bobby
> I found some components will use the appId in
> mozIApplicationClearPrivateDataParams to get the manifestURL, like
> dom/simplepush/PushService.jsm, AlarmService.jsm, InterAppCommService.jsm.

We should still be able to get manifestURL from the appId that we get by passing OriginAttributesPattern, so the long-term plan for manifestURL shouldn't affect what we do in this bug.

I'll let Jonas comment on the long-term plan, if there is one.

Comment 4

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Bobby Holley (:bholley) from comment #3)
> (In reply to Yoshi Huang[:allstars.chh] from comment #2)
> > Hi Jonas and Bobby
> > I found some components will use the appId in
> > mozIApplicationClearPrivateDataParams to get the manifestURL, like
> > dom/simplepush/PushService.jsm, AlarmService.jsm, InterAppCommService.jsm.
> 
> We should still be able to get manifestURL from the appId that we get by
> passing OriginAttributesPattern, so the long-term plan for manifestURL
> shouldn't affect what we do in this bug.
> 

Right now we mainly get manifestURL from AppsService, but for signed content it may come from http cache without actually installed. So I am not sure if AppsService can get the url.

Comment 5

[Bobby Holley (:bholley)]

(In reply to Yoshi Huang[:allstars.chh] from comment #4)
> > We should still be able to get manifestURL from the appId that we get by
> > passing OriginAttributesPattern, so the long-term plan for manifestURL
> > shouldn't affect what we do in this bug.
> > 
> 
> Right now we mainly get manifestURL from AppsService, but for signed content
> it may come from http cache without actually installed. So I am not sure if
> AppsService can get the url.

Sure - we may need to change it for signedPkg stuff (Jonas can tell us whether it's necessary). I'm just saying that it's a separate concern that doesn't affect what we want to do in this bug.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

For signed content we won't use an appid, but rather a new "signedPkg" thing that we'll add to OriginAttributes (bug 1163254).

Appids should always be possible to map to a manifestURL using the AppsService

Comment 7

[Honza Bambas (:mayhemer)]

This no longer blocks HTTP cache/OrignAttribs bugs (1165269, 1165256), but may collide with them, since I'm moving some of the implementation and also network unit tests to use the "clear-origin-data" notification.

Maybe this should rather depend at least on bug 1165269 to avoid unnecessary collisions?