Closed Bug 995310 Opened 6 years ago Closed 6 years ago

"metro" folder being installed (linux, osx, win)

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect
Not set

Tracking

(firefox30+ verified, firefox31+ verified, firefox32+ verified)

VERIFIED FIXED
mozilla32
Tracking Status
firefox30 + verified
firefox31 + verified
firefox32 + verified

People

(Reporter: kjozwiak, Assigned: emtwo)

References

Details

Attachments

(1 file)

While I was working another issue in OSX, I noticed that there was a "metro" folder created when I installed Nightly... So I checked on other OS's and builds:

Windows 8.1 Updated x64:

C:\Users\kjozQA\AppData\Roaming\Mozilla\Firefox\Profiles\85a91ebv.default\metro
* Reproduced on Nightly and Aurora (metro folder is empty)

Ubuntu 13.10 x64:

/home/kjozwiak/.mozilla/firefox/08azk6ab.default/metro
* Reproduced on both Nightly and Aurora (metro folder is empty)

OSX 10.9.2 x64:

/Users/kjozwiak/Library/Application Support/Firefox/Profiles/5hf4e5q3.default/metro
* Reproduced on both Nightly and Aurora (metro folder is empty)

This is definitely a lower priority issue but we should remove the "metro" folder from Nightly and Aurora, especially on OSX and Linux as metro was never even on those platforms.

Used the following builds:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-11-03-02-01-mozilla-central/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-11-00-40-02-mozilla-aurora/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/29.0b7/
QA Whiteboard: [qa+]
We are too late to take on changes to fix this in FF30 but it would be great to see this unnecessary folder be cleaned up in future versions to avoid confusion.
Duplicate of this bug: 1016864
See comment 0 from duped bug:

I created a new test profile on OS X and saw a "metro" directory was created in my profile which is weird since metro doesn't run on OS X. The code to create the directory should probably only run in metro-enabled builds to avoid cluttering the profile folder.

Caused by http://hg.mozilla.org/mozilla-central/rev/c0ea0b4d69f7#l1.29
Looking at the changeset that caused this, it seems like a simple backout - Marina can you prepare a patch?
Flags: needinfo?(msamuel)
If this is a no-risk backout, we could still consider it for FF30 - resetting the flags - as it might be better to never ship this than to clean it up later.
I confirm that it should be a trivial backout.
Attached patch v1Splinter Review
Instead of backing out, I added a check so that the folder is only created in the metro environment. That way there is no need to back out the metro changes as well (since it looks like metro hasn't been removed in nightly).

Does that sound reasonable?
Attachment #8430962 - Flags: review?(dteller)
Flags: needinfo?(msamuel)
Comment on attachment 8430962 [details] [diff] [review]
v1

Review of attachment 8430962 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks.
Attachment #8430962 - Flags: review?(dteller) → review+
Ok let's get this way tested out on a nightly and nominate for Beta/Aurora uplift.
https://hg.mozilla.org/mozilla-central/rev/24b5a8937a60
Assignee: nobody → msamuel
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
Can we get the uplift nomination here? Today is the day we build the final RC.
Flags: needinfo?(msamuel)
Comment on attachment 8430962 [details] [diff] [review]
v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 872206

User impact if declined: Users get an metro folder in their profile directory even when there is no metro enabled. This is probably confusing to users

Testing completed (on m-c, etc.): tested on m-c that the metro folder isn't in my profile

Risk to taking this patch (and alternatives if risky): Low risk, added a conditional check for when the folder is created

String or IDL/UUID changes made by this patch:none
Attachment #8430962 - Flags: approval-mozilla-beta?
Attachment #8430962 - Flags: approval-mozilla-aurora?
Flags: needinfo?(msamuel)
Reproduced the original issue before verification using the following build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-29-11-35-10-mozilla-central/

Once reproduced, used the following m-c build for verification:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-06-02-03-02-02-mozilla-central/

- installed the latest m-c on Win 8.1 and ensured that the "metro" folder wasn't being created
- installed the latest m-c on Ubuntu 13.10 and ensured that the "metro" folder wasn't being created
- installed the latest m-c on OSX 10.9.3 and ensured that the "metro" folder wasn't being created
Attachment #8430962 - Flags: approval-mozilla-beta?
Attachment #8430962 - Flags: approval-mozilla-beta+
Attachment #8430962 - Flags: approval-mozilla-aurora?
Attachment #8430962 - Flags: approval-mozilla-aurora+
Reproduced the original issue before verification using the following build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-29-00-40-03-mozilla-aurora/

Once reproduced, used the following aurora build for verification:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-06-03-00-40-03-mozilla-aurora/

- installed the latest aurora on Win 8.1 and ensured that the "metro" folder wasn't being created
- installed the latest aurora on Ubuntu 13.10 and ensured that the "metro" folder wasn't being created
- installed the latest aurora on OSX 10.9.3 and ensured that the "metro" folder wasn't being created

Latest beta build is from May 30, will need to wait for a new build to be created to verify under the beta channel.
Reproduced the issue on Firefox 30 beta 9.

Confirming that the Metro folder is no longer created when installing Firefox 30 RC (build ID: 20140605174243) on Windows 8.1 64bit, Windows 7 64bit, Ubuntu 12.04 and Mac OS X 10.9.
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 32 → mozilla32
You need to log in before you can comment on or make changes to this bug.