902486 - Firefox doesn't start on Mac OS X using a remote profile from Windows

Status: RESOLVED INCOMPLETE

(Toolkit :: Storage, defect)

Description

[Simona Badau, Desktop QA]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130806104538

Steps to reproduce:
1. Share a Firefox profile on a Windows computer (in my case on a Windows 8 64-bit machine)
2. From a Mac OS X machine - start Firefox with the profile manager
3. Create a new profile, select Choose Folder, select the Windows machine from step 1, select the shared profile, click Done and open Firefox with that profile.

Expected results: 
Firefox is successfully launched.

Actual results:
Firefox does not start (if I check the Activity monitor I get the message that Firefox is not responding).

Notes:
Reproducible on the latest Nightly, the latest Aurora and  Firefox 24 beta 1.
Firefox 23 is successfully launched.

Comment 1

[bhavana bajaj [:bajaj]]

Gavin would you be able to help with investigation here ? else can you please direct me to the right folks ?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

In general this is not a supported use case, so I wouldn't worry about tracking this.

We'd need a regression range to narrow down the specific cause, but I would not treat this as a high priority.

Comment 3

[Tracy Walker [:tracy]]

Interesting.  I'll look into why this is in QA's sign-off path. I wouldn't have nominated it otherwise.

Comment 4

[u279076]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #2)
> In general this is not a supported use case, so I wouldn't worry about
> tracking this.

That surprises me since we did chemspill Firefox (I think it was Fx20) for software updates not working on a system using remote profiles. Is this no longer the case?

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Using remote profiles is supported, using the same profile across different operating systems is not.

Comment 6

[Simona Badau, Desktop QA]

Last good Nightly: 2013-06-06
First bad Nighrly: 2013-06-07

Pushlog: 
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=204de5b7e0a6&tochange=dc8e78ed8c44

Comment 7

[u279076]

(In reply to Simona B [QA] from comment #6)
> Last good Nightly: 2013-06-06
> First bad Nighrly: 2013-06-07
> 
> Pushlog: 
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=204de5b7e0a6&tochange=dc8e78ed8c44

Nothing in that pushlog stands out to me but there are a lot of changes. Any chance you could narrow that down more using tinderbox or inbound?

Comment 8

[Simona Badau, Desktop QA]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #7)
> (In reply to Simona B [QA] from comment #6)
> > Last good Nightly: 2013-06-06
> > First bad Nighrly: 2013-06-07
> > 
> > Pushlog: 
> > http://hg.mozilla.org/mozilla-central/
> > pushloghtml?fromchange=204de5b7e0a6&tochange=dc8e78ed8c44
> 
> Nothing in that pushlog stands out to me but there are a lot of changes. Any
> chance you could narrow that down more using tinderbox or inbound?

The changeset where the issue is first reproducible is:
dc8e78ed8c44	Nathan Froyd — Bug 878411 - define xFetch and xUnfetch methods in TelemetryVFS file objects; r=mak

Comment 9

[u279076]

Nathan, can you have a look at this?

Comment 10

[Nathan Froyd [:froydnj]]

I'm guessing this is some sort of problem with SQLite, since the relevant changes affected how SQLite works.

I'm guessing we're not keen to bump SQLite versions (if it's even something easy to fix) on beta...

But if, like Gavin says in comment 5, this is not a supported use case, why are we worrying about it?

Comment 11

[u279076]

Fair point Nathan. Gavin, if this is unsupported will we ever support it? If not I vote we should probably just WONTFIX this bug.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Well, if it used to work and we just broke it and it's easy to fix, we probably should, but I wouldn't invest a lot of time/attention in it.

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(hard guess) could be related to this fix http://www.sqlite.org/src/info/0ae7e75b21 that will be in 3.8.0, the only way to be sure would be to test that though.
Off-hand I don't see why our changes should create such issue.

Comment 14

[Nathan Froyd [:froydnj]]

https://bugzilla.mozilla.org/show_bug.cgi?id=918612#c29 says that setting the preference storage.nfs_filesystem to true fixed similar problems; it might be worth seeing if doing the same thing works in this case.

Would be fantastic if we could tell people to do this automatically...

Comment 15

[Simona Badau, Desktop QA]

(In reply to Nathan Froyd (:froydnj) from comment #14)
> https://bugzilla.mozilla.org/show_bug.cgi?id=918612#c29 says that setting
> the preference storage.nfs_filesystem to true fixed similar problems; it
> might be worth seeing if doing the same thing works in this case.

Firefox starts when the preference storage.nfs_filesystem is set to true, but tabs can't be closed and Firefox is not responding if used a little too intense (for e.g I'm opening a YouTube video).

Comment 16

[Wayne Mery (:wsmwk)]

is it better now that bug 878411 is fixed?