866247 - Map "MetroFirefox" to "Firefox" for URL handling for application updates

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Brian R. Bondy [:bbondy]]

Updates in Metro and Desktop are the same MAR file. To avoid hacking in special case handling ( like this: https://bug794937.bugzilla.mozilla.org/attachment.cgi?id=741447 ) for Metro Firefox into updater code, we'd like to map MetroFirefox to Firefox as per the example below.  

So map:

https://aus3.mozilla.org/update/3/MetroFirefox/23.0a1/20130423135252/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.2.0.0%20(x64)/default/default/update.xml?force=1

to:

https://aus3.mozilla.org/update/3/Firefox/23.0a1/20130423135252/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.2.0.0%20(x64)/default/default/update.xml?force=1

This should work for any similar app update URL (for example the partial and full MAR as well).

Thanks for your help!

Comment 1

[Brian R. Bondy [:bbondy]]

So both example URLs above would serve the same XML file.

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Found in triage. 

Not sure if this is a RelEng or webdev or IT change, so lets start in RelEng component and see where it ends up after investigation.

Unstated, but I assume this is needed for nightly-m-c builds, aurora, beta and release?

Comment 3

[[e-mail] (:bhearsum)]

Is there a reason MetroFirefox can't just send Firefox to the server? Are we sending MetroFirefox for some sort of future proofing in case we want to serve separate updates later?

Comment 4

[Robert Strong (they/them - no direct email)]

The value is provided by the app's application.ini and as with all toolkit components we avoid adding app specific one off code. Though we could one off it in the code I am loathe to add client side code to do so and this will allow us flexibility if needed.

Comment 5

[Brian R. Bondy [:bbondy]]

> Unstated, but I assume this is needed for nightly-m-c builds, aurora, 
> beta and release?

Yup MetroFirefox -> Firefox for all channels.

Comment 6

[[e-mail] (:bhearsum)]

(In reply to Robert Strong [:rstrong] (do not email) from comment #4)
> The value is provided by the app's application.ini and as with all toolkit
> components we avoid adding app specific one off code. Though we could one
> off it in the code I am loathe to add client side code to do so and this
> will allow us flexibility if needed.

OK.

I think we can do this in the current AUS with a simple symlink. This probably means we need to make some adjustments to the config file to make sure MetroFirefox follows throttling and platform deprecation rules.

There's no way to test this without making it live for all channels though. Any chance you can do a test by hacking in "MetroFirefoxTest" as the product? If so, I can make that live today.

In Balrog (the new AUS server software that we're working on), we can probably do this with an additional rule for now...though it doesn't fit very nicely with some of the schema...we should probably see if we can do better there. Might want to take that to a separate bug.

Comment 7

[Brian R. Bondy [:bbondy]]

(In reply to Ben Hearsum [:bhearsum] from comment #6)
> (In reply to Robert Strong [:rstrong] (do not email) from comment #4)
> > The value is provided by the app's application.ini and as with all toolkit
> > components we avoid adding app specific one off code. Though we could one
> > off it in the code I am loathe to add client side code to do so and this
> > will allow us flexibility if needed.
> 
> OK.
> 
> I think we can do this in the current AUS with a simple symlink. This
> probably means we need to make some adjustments to the config file to make
> sure MetroFirefox follows throttling and platform deprecation rules.
> 
> There's no way to test this without making it live for all channels though.
> Any chance you can do a test by hacking in "MetroFirefoxTest" as the
> product? If so, I can make that live today.
> 
> In Balrog (the new AUS server software that we're working on), we can
> probably do this with an additional rule for now...though it doesn't fit
> very nicely with some of the schema...we should probably see if we can do
> better there. Might want to take that to a separate bug.

Live is OK, only the oak branch is using the MetroFirefox update link util bug 794937 lands.  And it will only land after testing.  I don't think we need to do the MetroFirefoxTest change.  You can put the URLs for MetroFirefox live for all channels.

Comment 8

[[e-mail] (:bhearsum)]

(In reply to Brian R. Bondy [:bbondy] from comment #7)
> (In reply to Ben Hearsum [:bhearsum] from comment #6)
> > (In reply to Robert Strong [:rstrong] (do not email) from comment #4)
> > > The value is provided by the app's application.ini and as with all toolkit
> > > components we avoid adding app specific one off code. Though we could one
> > > off it in the code I am loathe to add client side code to do so and this
> > > will allow us flexibility if needed.
> > 
> > OK.
> > 
> > I think we can do this in the current AUS with a simple symlink. This
> > probably means we need to make some adjustments to the config file to make
> > sure MetroFirefox follows throttling and platform deprecation rules.
> > 
> > There's no way to test this without making it live for all channels though.
> > Any chance you can do a test by hacking in "MetroFirefoxTest" as the
> > product? If so, I can make that live today.
> > 
> > In Balrog (the new AUS server software that we're working on), we can
> > probably do this with an additional rule for now...though it doesn't fit
> > very nicely with some of the schema...we should probably see if we can do
> > better there. Might want to take that to a separate bug.
> 
> Live is OK, only the oak branch is using the MetroFirefox update link util
> bug 794937 lands.  And it will only land after testing.  I don't think we
> need to do the MetroFirefoxTest change.  You can put the URLs for
> MetroFirefox live for all channels.

OK, I'll make this happen shortly. We may want to change the implementation later, but I can definitely get you unblocked for now.

Comment 9

[Brian R. Bondy [:bbondy]]

Awesome, thanks so much!

Comment 10

[[e-mail] (:bhearsum)]

Attachment: set up MetroFirefox for oak

I've also added a symlink on AUS:
[bhearsum@dp-ausstage01 2]$ pwd
/opt/aus2/incoming/2
[bhearsum@dp-ausstage01 2]$ ls -l
total 12
drwxrwxr-x 10 ffxbld   ffxbld 4096 Abr 26 05:23 Fennec
drwxr-xr-x 21 ffxbld   ffxbld 4096 Dis 20 16:50 Firefox
lrwxrwxrwx  1 root     root      7 Abr 26 14:09 MetroFirefox -> Firefox
drwxr-xr-x 12 tbirdbld users  4096 Peb 14 04:27 Thunderbird


I did a quick test of this on dp-ausstage01 and it worked fine.

Comment 11

[[e-mail] (:bhearsum)]

Should be working now. Eg: https://aus3.mozilla.org/update/3/MetroFirefox/15.0a1/20120519040218/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.1.1.0%20%28x64%29/default/default/update.xml?force=1

Comment 12

[Brian R. Bondy [:bbondy]]

Works great thank you, I think this can be resolved now and I'll file a new bug if I run into any problems.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

FYI, we'll need to adjust the update server config when that work lands on central, and also support it in the release automation as it rides the trains to beta/release. Is there a bug we can track for that ?

Comment 14

[Brian R. Bondy [:bbondy]]

> Is there a bug we can track for that ?

Nope, did you want me to post a new one or did you want this re-opened?

Comment 15

[[e-mail] (:bhearsum)]

I was thinking about the quick hack I did here a bit more and the more I think about it the more unintuitive it seems to me that we're sending different application names when the server just combines them back together. As long as they're packaged together, there's no use case for app-specific updates.

However, update pings might be critical for Metrics data depending on whether or not MetroFirefox sends blocklist pings. If that's the case, that may force our hand on this matter. Brian said he was going to ask about this at a meeting today.

If we don't need separate application names for Metrics or another reason, it seems like we get to choose between code on the client side like Brian described in comment #0, or code on the server side to treat Firefox and MetroFirefox the same.

Comment 16

[Robert Strong (they/them - no direct email)]

Another consideration... this "one-off" code change could be on millions of client systems or in AUS... personally I would much rather it be in AUS.

Comment 17

[Brian R. Bondy [:bbondy]]

So we're updating on m-c now, but we can't update via the Metro interface because this is only on Oak. Is it possible to get this change on all branches? 

Let me know if you'd rather me file a new bug instead of re-opening this one.
Thanks!

Comment 18

[[e-mail] (:bhearsum)]

I'm still not sold on this as anything except a quick hack, but I don't want to block.

Comment 19

[Brian R. Bondy [:bbondy]]

At this point I'm looking for the long term solution, rstrong are you OK with using the MOZ_APP_NAME instead of appinfo name when isMetro is true hack in toolkit/mozapps/update code? If so I'll resolve this and post a new bug for that.  

Otherwise who can make the final call on if we can do URLs with MetroFirefox as a redirect as a permanent solution?

Comment 20

[Robert Strong (they/them - no direct email)]

So, the choices are:
1. map MetroFirefox to Firefox in aus.
2. add one off in client code across all of our clients in toolkit code which all apps use.
3. use a define which I believe is what was proposed in comment #19.
4. create a new value that is the same for non-metro and metro Firefox in XULAppInfo.
5. we could even go for the crazy extra work solution and create another set of mar files for metro even though they are currently using the same as the regular Firefox mars!

Responses:
1. this gives us the greatest flexibility if we ever need to create a one-off mar or break updates on non-metro vs. metro.
2. I don't want the client code one-off'd for the reasons previously noted.
3. defines break using Firefox as xulrunner where the xulrunner app specifies its own name. I know this isn't possible on Metro today but it might be possible in the future.
4. this is ugly and doesn't have the flexibility but could be done.
5. no one wants to do this... do they? This also provides the same flexibility as 1.

Comment 21

[Brian R. Bondy [:bbondy]]

Sorry to bug you again :D
Can we pretty please do 1?

Comment 22

[[e-mail] (:bhearsum)]

I still don't think this is a great solution, but like I said...I'm not going to be a blocker here. It's too late for me to do this today, I'll get it done on my Monday morning.

Comment 23

[Brian R. Bondy [:bbondy]]

(In reply to Ben Hearsum [:bhearsum] from comment #22)
> I still don't think this is a great solution, but like I said...I'm not
> going to be a blocker here. 

Ya, I don't think there is a really good solution.  We'd need this for all channels, but of main importance is (stay like it is on oak, mozilla-central, aurora, beta, release).

> It's too late for me to do this today, I'll get
> it done on my Monday morning.

No problem, that sounds great, thank you!

Comment 24

[[e-mail] (:bhearsum)]

Attachment: same for central

Comment 25

[[e-mail] (:bhearsum)]

Comment on attachment 757365 [details] [diff] [review]
same for central

(bbgraph)➜  inc  cvs tag AUS2_PRODUCTION config-dist.php 
W config-dist.php : AUS2_PRODUCTION already exists on version 1.258 : NOT MOVING tag to version 1.259
(bbgraph)➜  inc  cvs tag -F AUS2_PRODUCTION config-dist.php
T config-dist.php

Comment 26

[[e-mail] (:bhearsum)]

Should be working now.