Closed Bug 1168777 Opened 6 years ago Closed 4 years ago

remove mozIApplicationClearPrivateDataParams

Categories

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

defect

Tracking

(firefox41 affected)

RESOLVED WONTFIX
FxOS-S8 (02Oct)
Tracking Status
firefox41 --- affected

People

(Reporter: allstars.chh, Assigned: allstars.chh)

References

Details

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.
No longer blocks: 1163254
Summary: remove appId and browserOnly from mozIApplicationClearPrivateDataParams → remove mozIApplicationClearPrivateDataParams
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
Flags: needinfo?(jonas)
Flags: needinfo?(bobbyholley)
(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.
Flags: needinfo?(bobbyholley)
(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.
(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.
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
Flags: needinfo?(jonas)
Blocks: 1165256
Blocks: 1165269
No longer depends on: 1165269
Priority: -- → P2
Target Milestone: --- → FxOS-S8 (02Oct)
Status: NEW → ASSIGNED
No longer blocks: 1165269
No longer blocks: 1165256
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?
Depends on: 1165269
Depends on: 1213577
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.