Closed
Bug 924919
Opened 11 years ago
Closed 11 years ago
Story - Profile Sharing Contingency
Categories
(Firefox for Metro Graveyard :: Browser, defect)
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=?
Reporter | ||
Comment 1•11 years ago
|
||
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
Reporter | ||
Comment 2•11 years ago
|
||
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.
Comment 3•11 years ago
|
||
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?
Comment 4•11 years ago
|
||
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.
Reporter | ||
Comment 5•11 years ago
|
||
> 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?
Comment 6•11 years ago
|
||
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?
Comment 7•11 years ago
|
||
(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...)
Comment 8•11 years ago
|
||
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.
Reporter | ||
Comment 9•11 years ago
|
||
(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
![]() |
||
Comment 10•11 years ago
|
||
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.
![]() |
||
Comment 11•11 years ago
|
||
A dev.platform post on this proposal would be good. The community can help identify issues.
Reporter | ||
Comment 12•11 years ago
|
||
Various startup cache for disk cache is being moved from this bug into bug 931846.
Reporter | ||
Comment 13•11 years ago
|
||
App name will be Firefox from both desktop and metro apps, but the id will differ.
Reporter | ||
Comment 14•11 years ago
|
||
Preferences will be kept separate, except for some extra code to sync important prefs from registry.
Reporter | ||
Comment 15•11 years ago
|
||
p=13 (mostly contingency)
Updated•11 years ago
|
Blocks: metrov1backlog
Summary: Unknown risks for profile sharing → Story - Profile Sharing Contingency
Whiteboard: feature=story c=tbd u=tbd p=13
Updated•11 years ago
|
Whiteboard: feature=story c=tbd u=tbd p=13 → [block28] feature=story c=tbd u=tbd p=13
Comment 16•11 years ago
|
||
-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
Reporter | ||
Comment 17•11 years ago
|
||
-5 for bug 924886
Whiteboard: [block28] feature=story c=tbd u=tbd p=12 → [block28] feature=story c=tbd u=tbd p=7
Reporter | ||
Comment 18•11 years ago
|
||
-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
Reporter | ||
Comment 19•11 years ago
|
||
+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
Reporter | ||
Comment 20•11 years ago
|
||
+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
Reporter | ||
Comment 21•11 years ago
|
||
-3 for bug 935178
Whiteboard: [block28] feature=story c=tbd u=tbd p=9 → [block28] feature=story c=tbd u=tbd p=6
Reporter | ||
Comment 22•11 years ago
|
||
-1 for bug 934032
Whiteboard: [block28] feature=story c=tbd u=tbd p=6 → [block28] feature=story c=tbd u=tbd p=5
Reporter | ||
Comment 23•11 years ago
|
||
+2 from bug 930067
Whiteboard: [block28] feature=story c=tbd u=tbd p=5 → [block28] feature=story c=tbd u=tbd p=7
Reporter | ||
Comment 24•11 years ago
|
||
-3 for bug 939092
Whiteboard: [block28] feature=story c=tbd u=tbd p=7 → [block28] feature=story c=tbd u=tbd p=4
Reporter | ||
Comment 25•11 years ago
|
||
-2 for bug 940168
Whiteboard: [block28] feature=story c=tbd u=tbd p=4 → [block28] feature=story c=tbd u=tbd p=2
Reporter | ||
Comment 26•11 years ago
|
||
-2 for bug 940101
Whiteboard: [block28] feature=story c=tbd u=tbd p=2 → [block28] feature=story c=tbd u=tbd p=0
Reporter | ||
Comment 27•11 years ago
|
||
Points are depleted and this is not tracking any individual issue, so closing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Reporter | ||
Updated•11 years ago
|
No longer blocks: metrov1backlog
Assignee | ||
Updated•10 years ago
|
OS: Windows 8 Metro → Windows 8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•