Closed Bug 924919 Opened 11 years ago Closed 11 years ago

Story - Profile Sharing Contingency

Categories

(Firefox for Metro Graveyard :: Browser, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bbondy, Unassigned)

References

Details

(Whiteboard: [block28] feature=story c=tbd u=tbd p=0)

This is an unknown.
We may want to just consolidate the app name and id.

p=?
Other possible unknowns:
- issues with a profile that is used by two apps that have different app ids (data stores, cache, ?)
- cached server side data (crash reports, telemetry, blocklist)
- add-ons (two different browser with two different sets in the same profile?)
- profile that is use by two apps having different app ids, or consolidate the app id and name.
- app name (MetroFirefox vs. Firefox)
- component registration
- xul cache
Summary: Investigate potential issues with a profile that is use by two apps having different app ids, or consolidate the app id and name. → Unknown risks for profile sharing
Feedback appreciated if you have any thoughts about the above: Gavin, bsmeberg?
For more context see bug 924860.
We aren't for sure doing this, but we're seriously discussing it.
This sounds a little nightmarish to me. We'd at least have to blow away some significant portions of some of the cache data.

I thought the initial metro release wasn't going to support addons... did that change?
We're still just exploring the idea of using a shared profile; I just added a link to our email discussion in bug 924860 comment 2.

Metro does not have any UI for installing or managing add-ons, and it sets extensions.enabledScopes=1 and xpinstall.enabled=false to limit the possibilities for installing extensions.  However, we have not disabled the ability to load extensions from the profile.

Metro has a different appID from desktop, so this would only be an issue only for extensions that explicitly target both Metro and desktop in their install.rdf.

The various caches sound like a more significant issue.
> This sounds a little nightmarish to me. We'd at least have to blow away some significant 
> portions of some of the cache data.

Couldn't we just dynamically detect which cache file to use based on if the user is running in Metro or not?
Yes, but it might be a fair bit of work. I don't think we have a good inventory of all the things that might depend. What about the HTTP cache, even? Will it correctly honor varies: User-Agent when the useragent is changed between metro and desktop?
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> Yes, but it might be a fair bit of work. I don't think we have a good
> inventory of all the things that might depend. What about the HTTP cache,
> even? Will it correctly honor varies: User-Agent when the useragent is
> changed between metro and desktop?

For now at least, the User-Agent is the same in Metro and desktop.  (But there's always a possible issue if we change that, or other things, in the future...)
I'm not sure if it's still true with the current setup, but at least in the past, it wasn't possible to open the sqlite databases in the profile in two different processes at the same time. And almost everything uses a sqlite database.
(In reply to Mike Hommey [:glandium] from comment #8)
> I'm not sure if it's still true with the current setup, but at least in the
> past, it wasn't possible to open the sqlite databases in the profile in two
> different processes at the same time. And almost everything uses a sqlite
> database.

The proposal is to only have one browser open at a time, but to have 2 modes. A user can choose to explicitly switch modes at any time.  Once switched, they will remain in the new mode until they switch back explicitly.  

A switch would close the current browser, and restart in the opposite environment.
So there's no risk of corruption or sqlite problems.
 
See bug 924860 comment 2 for more discussion
A couple things to look at - in the profile we have an extensions.ini file, which for desktop includes a default theme extension. Metro doesn't create this but we don't want to mess this up for desktop. I wonder what happens if we create a metro profile first, and then try to run desktop.

Also we should look at mimeTypes.rdf which handles things like file attachment handling settings.
A dev.platform post on this proposal would be good. The community can help identify issues.
Various startup cache for disk cache is being moved from this bug into bug 931846.
App name will be Firefox from both desktop and metro apps, but the id will differ.
Preferences will be kept separate, except for some extra code to sync important prefs from registry.
p=13 (mostly contingency)
Summary: Unknown risks for profile sharing → Story - Profile Sharing Contingency
Whiteboard: feature=story c=tbd u=tbd p=13
Whiteboard: feature=story c=tbd u=tbd p=13 → [block28] feature=story c=tbd u=tbd p=13
-1 from the point addition to Bug 932664.
Whiteboard: [block28] feature=story c=tbd u=tbd p=13 → [block28] feature=story c=tbd u=tbd p=12
-5 for bug 924886
Whiteboard: [block28] feature=story c=tbd u=tbd p=12 → [block28] feature=story c=tbd u=tbd p=7
-2 for UX branch work in bug 934032
Whiteboard: [block28] feature=story c=tbd u=tbd p=7 → [block28] feature=story c=tbd u=tbd p=5
+2 from bug 928432 which turned out to be invalid
Whiteboard: [block28] feature=story c=tbd u=tbd p=5 → [block28] feature=story c=tbd u=tbd p=7
+2 from reduction in points of bug 924894.
Whiteboard: [block28] feature=story c=tbd u=tbd p=7 → [block28] feature=story c=tbd u=tbd p=9
-3 for bug 935178
Whiteboard: [block28] feature=story c=tbd u=tbd p=9 → [block28] feature=story c=tbd u=tbd p=6
-1 for bug 934032
Whiteboard: [block28] feature=story c=tbd u=tbd p=6 → [block28] feature=story c=tbd u=tbd p=5
+2 from bug 930067
Whiteboard: [block28] feature=story c=tbd u=tbd p=5 → [block28] feature=story c=tbd u=tbd p=7
-3 for bug 939092
Whiteboard: [block28] feature=story c=tbd u=tbd p=7 → [block28] feature=story c=tbd u=tbd p=4
-2 for bug 940168
Whiteboard: [block28] feature=story c=tbd u=tbd p=4 → [block28] feature=story c=tbd u=tbd p=2
-2 for bug 940101
Whiteboard: [block28] feature=story c=tbd u=tbd p=2 → [block28] feature=story c=tbd u=tbd p=0
Points are depleted and this is not tracking any individual issue, so closing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
No longer blocks: metrov1backlog
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.