Closed Bug 1232679 Opened 9 years ago Closed 8 years ago

Improve the Firefox start menu tile on Windows 8/10

Categories

(Firefox :: General, defect, P3)

43 Branch
x86
Windows 10
defect
Points:
8

Tracking

()

VERIFIED FIXED
Firefox 50
Tracking Status
firefox50 --- verified

People

(Reporter: verdi, Assigned: ktbee, Mentored)

References

Details

(Whiteboard: [qx][onboarding][outreachy-12])

Attachments

(11 files, 12 obsolete files)

37.58 KB, image/jpeg
Details
139.71 KB, image/png
Details
174.50 KB, image/png
Details
9.82 KB, image/png
Details
30.87 KB, image/png
Details
10.84 KB, image/png
Details
38.59 KB, image/png
Details
9.68 KB, image/png
Details
33.34 KB, image/png
Details
235.84 KB, patch
Details | Diff | Splinter Review
138.20 KB, image/jpeg
Details
Attached image startmenutiles.jpg
The Firefox logo is fairly small in the tile in the Windows 10 start menu. We should consider making it bigger and making the tile background complimentary.
Whiteboard: [qx][onboarding]
A little note on the background color: Microsoft Office (the non-Metro version) has custom background colors and so does Chrome, so that seems to be possible now.
This is a duplicate of bug 1050608, right?
Flags: needinfo?(mverdi)
Attached image tile-colors.png
(In reply to :Gijs Kruitbosch (away 18-28 Dec.) from comment #2)
> This is a duplicate of bug 1050608, right?

I guess so. I was also pointed to bug 1092164. I'm attaching a mock of a larger logo with 3 different background colors from our style guide.
Flags: needinfo?(mverdi)
See Also: → 852586
Mentor: jaws
Whiteboard: [qx][onboarding] → [qx][onboarding][outreachy-12]
Points: --- → 8
Summary: Improve the Firefox start menu tile on Windows 10 → Improve the Firefox start menu tile on Windows 8/10
I've noticed the following when comparing Chrome and Fx resources: the order of icons in our windows binary are ascending by size; the reverse for Chrome.

Windows app tiles pick the default icon (i.e. the first it can find) from the applications' binary when a tile is created. If we 'simply' reverse the order of our icons, we'll be on-par with Chrome.

Picking a custom tile color seems like a project way out of the scope of this bug, because extensive DDGo'ing didn't reveal an obvious answer apart from wrapping all the things in an AppX package. Or something.
Stephen, how 'simple' is it to provide branding .ico's in reverse order?
Flags: needinfo?(shorlander)
(In reply to Mike de Boer [:mikedeboer] from comment #7)
> Stephen, how 'simple' is it to provide branding .ico's in reverse order?

I just tried this - needed a clobber to get a firefox.exe with icons in the same order as firefox.ico - but pinning it to Start in Win8.1 didn't give me a bigger icon, unfortunately.
Flags: needinfo?(shorlander)
(In reply to Mike de Boer [:mikedeboer] from comment #6)
> If we 'simply' reverse the
> order of our icons, we'll be on-par with Chrome.

If by "on-par with Chrome" you mean we'll have the Firefox logo be 95% the height and width of the tile, I don't think that's the right solution. I don't think the logo should be quite that big.
(In reply to Verdi [:verdi] from comment #9)
> (In reply to Mike de Boer [:mikedeboer] from comment #6)
> > If we 'simply' reverse the
> > order of our icons, we'll be on-par with Chrome.
> 
> If by "on-par with Chrome" you mean we'll have the Firefox logo be 95% the
> height and width of the tile, I don't think that's the right solution. I
> don't think the logo should be quite that big.

Can you explain why you think 95% is not ideal? Our logo is much more visibly recognizable and easier to notice in a blur test compared to reading the text of the application name. There is also likely some Fitts' Law application here, since users may presume the larger logo as a larger click area.
To correct myself a little bit, I do prefer the size of the Firefox logo as seen in your https://bugzilla.mozilla.org/attachment.cgi?id=8699461 attachment. I like that size because it doesn't look like it is being squished by the tile, there is room for the logo to breathe.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #10) 
> Can you explain why you think 95% is not ideal? 

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #11)
>I like that size because it doesn't look like it is being
> squished by the tile, there is room for the logo to breathe.

That's pretty much it. :)  My other thought was that the background color would help make it stand out better and provide the larger visual target.
We will need to install a file to the application directory along with the associated images that we want to show for this.

The file should be called firefox.VisualElementsManifest.xml, where "firefox" is the name of the executable that should be referenced. Inside of the file, we will include references to the images that we want to show on the tile, as well as the background colors.

This is working for me locally,
<Application xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
  <VisualElements
      ShowNameOnSquare150x150Logo='on'
      Square150x150Logo='jaws150.jpg'
      Square70x70Logo='jaws70.jpg'
      ForegroundText='light'
      BackgroundColor='#323232'/>
</Application>

After creating this file in the application directory, along with placing those images at the specified paths, run PowerShell as administrator and perform the following commands:

0. Make sure to "unpin" Firefox from the Start Menu
1. Change working directory to the start menu directory that includes the shortcut to Firefox
2. (ls ./Nightly.lnk).lastwritetime = get-date
2a. This would be Firefox.lnk if I was working on a release build.
3. Pin Firefox to the Start Menu
Assignee: nobody → jaws
Status: NEW → ASSIGNED
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #13)

> 0. Make sure to "unpin" Firefox from the Start Menu
...
> 2. (ls ./Nightly.lnk).lastwritetime = get-date

Hmm, does this mean we might have issues getting the new icon to show up for users who already have Firefox installed/pinned?
We will likely need the updater to touch firefox.exe, as my local firefox.exe hadn't been touched in a couple months even though it is for my Nightly build which I update every day.

I believe that the tile will update without unpinning/repinning, though it may take some time for Windows to invalidate the cache. The unpinning/touching/pinning rebuilds the cache.
See Also: → 844270
Searched via stackoverflow http://stackoverflow.com/questions/20839728/windows-8-1-possible-to-change-tile-colour/20853069#20853069

The result backed what :jaws said in comment 14

According to MS doc
https://msdn.microsoft.com/en-us/library/windows/apps/dn393983.aspx

The tile customizations can do
* Custom, full-bleed images
* A specified background color
* The option to show or hide the app name on the tile
* Specified light or dark text color if you choose to show the app name


Verdi, could you help find the right person to provide:

1. 70x70 logo (70x70Logo.png)
2. 150x150 logo (150x150Logo.png)
3. background color
4. show or hide the app name on the tile
5. app name color if want to show the app name
Flags: needinfo?(mverdi)
(In reply to Fred Lin [:gasolin] from comment #16)
> Verdi, could you help find the right person to provide:
> 
> 1. 70x70 logo (70x70Logo.png)
> 2. 150x150 logo (150x150Logo.png)
> 3. background color
> 4. show or hide the app name on the tile
> 5. app name color if want to show the app name

I can provide all of that. Leaving the NI as a reminder.
Attached image firefox_logo-only_RGB_cropped_150.png (obsolete) —
Background color should be: #0996f8
Show the app name
App name color: White
Flags: needinfo?(mverdi)
Attached image firefox_logo-only_RGB_70.png (obsolete) —
Verdi, we will need colors and icons for DevEdition and Nightly as well.
Flags: needinfo?(mverdi)
Attached image firefox_logo-only_RGB_70.png (obsolete) —
Attachment #8751408 - Attachment is obsolete: true
Flags: needinfo?(mverdi)
Attached image firefox_logo-only_RGB_150.png (obsolete) —
Attachment #8751407 - Attachment is obsolete: true
Attached image firefox-nightly_logo-only_RGB_70.png (obsolete) —
Attached image firefox-nightly_logo-only_RGB_150.png (obsolete) —
Ok, all three tiles get:
Show the app name
App name color: White

Release background: #0996f8
Dev Edition & Nightly background: #14171a
Katie, would you like to take this bug once you're finished with bug 1061747? See comment #13 and on for details on how to fix this bug. We will need to update /browser/installer/package-manifest.in to get the file installed next to firefox.exe. Also, you can look at the patch in bug 844270 to see what was done when this was implemented for Metro Firefox (which we never shipped).
Flags: needinfo?(kbroida)
(In reply to Verdi [:verdi] from comment #22)
> Created attachment 8751856 [details]
> firefox_logo-only_RGB_150.png

This logo (and all the others, for that matter) has a greyish-outline around, which is particularly noticeable on light backgrounds. (View this attachment in Firefox, and notice it on the yellow part of the tail and the edge of the planet.)

Pretty sure I've seen this happen before, I want to say it had something to do with transparency and CMYK colorspaces, or something like that. Shorlander might know more?
(In reply to Justin Dolske [:Dolske] from comment #29)
> Pretty sure I've seen this happen before, I want to say it had something to
> do with transparency and CMYK colorspaces, or something like that.

D'oh! Yep. Uploading new versions.
Attachment #8751854 - Attachment is obsolete: true
Attachment #8751856 - Attachment is obsolete: true
Attachment #8751857 - Attachment is obsolete: true
Attachment #8751858 - Attachment is obsolete: true
Attachment #8751859 - Attachment is obsolete: true
Attachment #8751860 - Attachment is obsolete: true
(In reply to Fred Lin [:gasolin] from comment #16)

> According to MS doc
> https://msdn.microsoft.com/en-us/library/windows/apps/dn393983.aspx
[...]
> 1. 70x70 logo (70x70Logo.png)
> 2. 150x150 logo (150x150Logo.png)

Actually, we're going to need more than that... See "Step 6: Specify images for scaling, localization, and high contrast".

There's nothing we need to localize, but we do need to have scaled images for hidpi support, and we should really take care of high-contrast while we're here.

For hidpi, looking at the DISPLAY_SCALING_MSWIN probe the most common scaling factors are 125%, 150%, 200%, and I see populations of 0.1-0.2% at 175% and 250%. 

(Well, the telemetry probe numbering is a little funky, and it's possible the 175% is actually 180%. That was a recommended level with Windows 8, but looks like they simplified things for Windows 10, so 175% is probably the right level to use now... https://blogs.technet.microsoft.com/askcore/2015/12/08/display-scaling-in-windows-10/)

Scaling from a non-native size works better when there are more pixels to deal with, so I think we'd be fine with just 100%, 125%, and 200%.

For high-contrast mode, https://msdn.microsoft.com/en-us/library/windows/apps/hh965372.aspx#Contrast says we can either just have a single asset for all mode, or different assets for HC-white and HC-black. I'm not sure what this ends up looking like or what we'd want to end up using, this could use some UX investigation.

So I think we'd need images for all combinations of:

* Small (70x70) and medium (150x150) tile size
* Scaling factor of 100%, 125%, 200%
* Normal, high-contrast. (or normal, HC-white, HC-black if we need to)
And for Katie's sake -- I don't think those images need to block progress on getting a basic test done. We'll either want to get them added before landing, or deal with them in a followup. (Although I'd probably lean towards wanting to get them done in one shot, to avoid multiple rounds of final testing.)
Yup! Sounds good, Jared. I'll work on this one next.
Flags: needinfo?(kbroida)
Blocks: 1271793
No longer blocks: qx-onboarding
I'm not sure that the method I'm using in the Makefile.in is the best way to go about making sure the VisualElementsManifest.xml file is copied to the application directory. Perhaps glandium would have some insight into this?
Attachment #8757008 - Flags: review?(mh+mozilla)
The patch is missing the VisualElements_* files. You will need to `hg add` them.

Also, were you able to get the name to show up correctly on the tile?
Assignee: jaws → kbroida
Flags: needinfo?(kbroida)
Comment on attachment 8757008 [details] [diff] [review]
Creates VisualElementsManifest.xml file and adds it to application directory.

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

The VisualElements* images are missing from the patch.

You'll also want to cover the unofficial branding (browser/branding/unofficial)

::: browser/installer/windows/Makefile.in
@@ +64,5 @@
>  	$(RM) -r $(CONFIG_DIR)
>  	$(MKDIR) $(CONFIG_DIR)
>  	$(INSTALL) $(addprefix $(srcdir)/,$(INSTALLER_FILES)) $(CONFIG_DIR)
>  	$(INSTALL) $(addprefix $(DIST)/branding/,$(BRANDING_FILES)) $(CONFIG_DIR)
> +	$(INSTALL) $(addprefix $(DIST)/branding/, $(TILE_RESOURCES)) $(CONFIG_DIR)/../../../app/

This is most certainly the worst place to do this.

What is the goal here? Do you want the firefox.VisualElementsManifest.xml file to be next to firefox.exe in the directory where firefox is installed? If so, I'll have to give this some thought. Or can it be anywhere?

It might be preferable to avoid adding the image files to the directory where firefox is installed, There are already a lot of files there. Does the xml file allow inline images (data: uri or otherwise)? if not, does it allow relative paths? if so, how about putting then in browser/? That can be done by putting the files in FINAL_TARGETS_FILES instead of BRANDING_FILES in branding-common.
Attachment #8757008 - Flags: review?(mh+mozilla)
Thank you for the feedback, Mike, I thought that I likely wasn't going about this the right way. According to Microsoft's documentation, the VisualElementsManifest.xml file has to be in the same directory as the executable file (https://msdn.microsoft.com/en-us/library/windows/apps/dn393983.aspx), so the goal is to add it next to firefox.exe. Let me know if there is a way you'd prefer I add this xml file to the executable file's directory.

As for the images, thank you for pointing out that they were missing from my commit, Jared. I didn't realize I could add PNGs to an HG commit, but I've added them to this patch (FWIW). Mike, I don't believe the images need to be in the same directory as the XML file, but all of the relative paths I've tried haven't yet allowed the images to load on the start menu tile. However, the documentation I linked to shows the images in a subfolder, so I'm not sure what's preventing the same file set up from working on my side. When I try to add them as a data URI encoded with Base64, the encoded logo images don't appear on the tile. This makes me think they have to remain separate files.

Jared, I was little confused about whether the tile name was actually broken or not, and looking at the documentation I started thinking it was just an issue with the unofficial build on my computer not being a full-fledged application (for example, I can't open it from the start menu tile, only when I use `./mach run`). I tried using `DisplayName='Mozilla Developers Preview'` in my XML file, but this didn't affect the tile and wasn't included as one of the options in the documentation linked above. I did find some other documentation that seemed to suggest I could set the DisplayName for Windows 10 tiles, but setting up my XML file in the way they suggested broke the tile completely and it only showed the default appearance (small icon, incorrect name and background color). Here's the documentation:

https://msdn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-creating-tiles

Even though Firefox doesn't currently have a VisualElementsManifest.xml file, it does have its correct name displayed in its start menu tile. This makes me think that Windows 10 pulls its name from somewhere besides the VisualElementManifest? I'm doing some reading on how app names are set on the start menu tiles in the first place, but at the moment I'm not clear on how it's set and whether adding a VisualElementsManifest will break it.
Attachment #8757008 - Attachment is obsolete: true
Flags: needinfo?(kbroida) → needinfo?(mh+mozilla)
The least worst way, currently, would be something like:

FINAL_TARGET_FILES['..'] += ['firefox.VisualElementsManifest.xml']

in branding-common.mozbuild.

Now, the problem is that hardcoding 'firefox' is not nice either, it should be based on CONFIG['MOZ_APP_NAME'], which makes things more complicated... You'd need to add a e.g. VisualElementsManifest.xml file in the tree, and have it installed as firefox.VisualElementsManifest.xml based on CONFIG['MOZ_APP_NAME'].

I don't remember if we have things to do that from moz.build yet. Mike or Nathan would know for sure.

Now, to fulfill my curiosity wrt relative paths, I tried to create the file in my install of Firefox on a Windows 2012 instance on EC2. Is it supposed to work on 2012 (it has a Windows 8-like tile-based start menu)? Does it require the file to be there when Firefox is installed, or should adding the file at any moment work?
Flags: needinfo?(nfroyd)
Flags: needinfo?(mshal)
Flags: needinfo?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #43)
> The least worst way, currently, would be something like:
> 
> FINAL_TARGET_FILES['..'] += ['firefox.VisualElementsManifest.xml']
> 
> in branding-common.mozbuild.
> 
> Now, the problem is that hardcoding 'firefox' is not nice either, it should
> be based on CONFIG['MOZ_APP_NAME'], which makes things more complicated...
> You'd need to add a e.g. VisualElementsManifest.xml file in the tree, and
> have it installed as firefox.VisualElementsManifest.xml based on
> CONFIG['MOZ_APP_NAME'].

We don't *need* to name the file firefox.VisualElementsManifest.xml. Placing the "firefox." prefix on the filename restricts the styling to the firefox.exe executable. If the prefix is not on the name, meaning the name is just VisualElementsManifest.xml, then the styling will apply to any executable in the directory.

We could go this route first to make the patch simpler.

> Now, to fulfill my curiosity wrt relative paths, I tried to create the file
> in my install of Firefox on a Windows 2012 instance on EC2. Is it supposed
> to work on 2012 (it has a Windows 8-like tile-based start menu)? Does it
> require the file to be there when Firefox is installed, or should adding the
> file at any moment work?

This is supposed to work starting in Windows 8.1+, of which it looks like Windows 2012 is the equivalent, though it is not mentioned in the documentation. You may need to invalidate your cache which can be done by following the PowerShell instructions I wrote in comment #13.
(In reply to Mike Hommey [:glandium] from comment #43)
> Now, the problem is that hardcoding 'firefox' is not nice either, it should
> be based on CONFIG['MOZ_APP_NAME'], which makes things more complicated...
> You'd need to add a e.g. VisualElementsManifest.xml file in the tree, and
> have it installed as firefox.VisualElementsManifest.xml based on
> CONFIG['MOZ_APP_NAME'].
> 
> I don't remember if we have things to do that from moz.build yet. Mike or
> Nathan would know for sure.

We don't have the ability to copy/symlink a file to a different filename in moz.build yet. It is something we'll need for a few other cases (eg: copying "firefox" to "firefox-bin" in browser/app/Makefile.in). So let me know if we want to do that here and I can try to implement it soon.
Flags: needinfo?(mshal)
mshal's answer seems sufficient.
Flags: needinfo?(nfroyd)
(In reply to Mike Hommey [:glandium] from comment #43)
> The least worst way, currently, would be something like:
> 
> FINAL_TARGET_FILES['..'] += ['firefox.VisualElementsManifest.xml']
> 
> in branding-common.mozbuild.

Thank you for this suggestion Mike, I found that I was able to copy VisualElementsManifest.xml and the image files into obj-dir/dist/bin/browser using FINAL_TARGET_FILES. However, I need them to be one directory higher in obj-dir/dist/bin. I think these files aren't being copied to the default FINALT_TARGET folder because DIST_SUBDIR has been set to `browser` in this makefile:

http://mxr.mozilla.org/mozilla-central/source/browser/installer/Makefile.in#6

I tried setting the FINAL_TARGET to be dist/bin using the following code in branding-common.mozbuild:

if CONFIG['MOZ_WIDGET_TOOLKIT'] == 'windows':
        FINAL_TARGET = 'dist/bin/'
        FINAL_TARGET_FILES += [
            'VisualElements_150.png',
            'VisualElements_70.png',
            'VisualElementsManifest.xml',
        ]

This works for copying the files into obj-dir/dist/bin , but when I try to build the installer with `mach build installer`, I get this error:

Error: c:\mozilla-source\mozilla-central\browser\installer\package-manifest.in:678: Missing file(s): bin/browser/defaults/preferences/firefox-branding.js

Do you have any suggestions for how I can have the FINAL_TARGET directory be the default dist/bin for just these VisualElements files?
Flags: needinfo?(mh+mozilla)
Changing FINAL_TARGET will make it changed for all the other things including branding-common.mozbuild, so it means that firefox-branding.js didn't end up in the right directory. As written in comment 43, FINAL_TARGET_FILES['..'] += ... should do what you want.
Flags: needinfo?(mh+mozilla)
Thank you for the clarification, Mike. I had misunderstood the "['..']" and thought it was referring to whatever sub-directory I needed. I'm now able to copy files into the directories I need, though I've been having some odd results with the VisualElementsManifest file itself. When I follow Jared's suggestion (and MSDN's documentation), the styling is correct for my object directory's start menu tile (I added this tile by right clicking on firefox.exe in obj-i686-pc-mingw32 and choosing "Pin to start"). However, the same VisualElementsManifest file doesn't apply the correct styling at all when I build an installer, install it, then add it to my start menu. The screenshot below shows how the styling differs:

http://screencast.com/t/yglLL7c4

I got a little closer by looking at how Chrome has their VisualElementsManfiest file set up, but it's still not perfect. They use "Logo" and "SmallLogo" versus "Square150x150Logo" and "Square70x70Logo", and I noticed that Firefox Metro did as well:

https://hg.mozilla.org/integration/mozilla-inbound/file/f017b36b080e/browser/branding/aurora/VisualElementsManifest.xml

Using "Logo" works for my obj-i686-pc-mingw32 executable shortcut as well. Here's a screenshot:

http://screencast.com/t/7ZP6Kye5xJlo

Long story short: I can get the tile to have the correct styling except for the full bleed images. Any thoughts on why they're not cooperating? This patch has the "Logo" and "SmallLogo" syntax that seems to be working best.
Attachment #8757374 - Attachment is obsolete: true
Maybe the cache needs to be invalidated per the instructions at the bottom of comment 13? We already will need to do something like that in the installer for upgrades.
Comment on attachment 8761670 [details] [diff] [review]
Patch v2 for customizing Windows 10 start menu tile

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

I tested the patch out on my machine with the installer and it works fine for me. Talking offline it seems that the issue before about it not updating may have been related to a step getting skipped.

::: browser/branding/aurora/VisualElementsManifest.xml
@@ +5,5 @@
> +      SmallLogo='VisualElements\VisualElements_70.png'
> +      ForegroundText='light'
> +      BackgroundColor='#14171a'/>
> +      <DefaultTile ShowName='allLogos'/>
> +      <SplashScreen Image='VisualElements\Logo.png'/>

Through our testing we found that the filename here is required but does not need to be correct for this to work. In fact, this patch already is using a nonexistant file for the path here. Please change this filename to 'DummyFileNameRequiredByWindows.png' so that this is self-documented for anybody looking at this file in the future.
Attachment #8761670 - Flags: review+
Comment on attachment 8761670 [details] [diff] [review]
Patch v2 for customizing Windows 10 start menu tile

glandium, can you review the build system changes?
Attachment #8761670 - Flags: review?(mh+mozilla)
Comment on attachment 8761670 [details] [diff] [review]
Patch v2 for customizing Windows 10 start menu tile

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

::: browser/branding/branding-common.mozbuild
@@ +13,5 @@
>      if CONFIG['MOZ_WIDGET_TOOLKIT'] == 'windows':
> +        FINAL_TARGET_FILES['..'] += [
> +            'VisualElementsManifest.xml',
> +        ]
> +        FINAL_TARGET_FILES['..'].VisualElements += [

It would be better, IMHO, to put these files under browser/, which, here, would just mean using FINAL_TARGET_FILES instead pf FINAL_TARGET_FILES['..'].VisualElements.

::: browser/branding/unofficial/VisualElementsManifest.xml
@@ +1,3 @@
> +<Application>
> +  <VisualElements
> +      DisplayName='Mozilla Developers Preview'

An interesting thing to note is that "Mozilla Developers Preview" is, afaict, only used in the installer and doesn't match the branding of the product itself.
Attachment #8761670 - Flags: review?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #53)
> An interesting thing to note is that "Mozilla Developers Preview" is,
> afaict, only used in the installer and doesn't match the branding of the
> product itself.

Should the DisplayName be different for the unofficial VisualElementsManifest.xml file? I had based the name on what branding.nsi said in the branding/unofficial folder, but I can make it match the branding of the product (whatever that branding might be).
Flags: needinfo?(mh+mozilla)
glandium, Jared just clarified for me that I should use the brandFullName that is specified in /browser/branding/***/locales/en-US/brand.dtd . No further questions at the moment!
Flags: needinfo?(mh+mozilla)
This patch updates the DisplayName for unoffical builds to "Nightly" and moves the VisualElements images to browser/
Attachment #8761670 - Attachment is obsolete: true
Attachment #8765471 - Flags: review?(mh+mozilla)
Comment on attachment 8765471 [details] [diff] [review]
Version v3 for customizing Windows 10 start menu tile

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

::: browser/branding/branding-common.mozbuild
@@ +13,5 @@
>      if CONFIG['MOZ_WIDGET_TOOLKIT'] == 'windows':
> +        FINAL_TARGET_FILES['..'] += [
> +            'VisualElementsManifest.xml',
> +        ]
> +        FINAL_TARGET_FILES.VisualElements += [

These files could go directly under browser/ instead of browser/VisualElements/
Attachment #8765471 - Flags: review?(mh+mozilla) → review+
(In reply to Mike Hommey [:glandium] from comment #57)
 
> These files could go directly under browser/ instead of
> browser/VisualElements/

Based on Dolske's comment (#36), I think we might end up needing a lot more images. If that's the case, would it be better to have them in a separate folder in browser/ ?
(In reply to Katie Broida [:ktbee] from comment #58)
> (In reply to Mike Hommey [:glandium] from comment #57)
>  
> > These files could go directly under browser/ instead of
> > browser/VisualElements/
> 
> Based on Dolske's comment (#36), I think we might end up needing a lot more
> images. If that's the case, would it be better to have them in a separate
> folder in browser/ ?

Please keep them in the separate folder since we'll be adding more images.
I've noticed that Chrome has VisualElementsManifest.xml files that cover both the Windows 8 format and Windows 10. I've updated this patch to have both formats and bring it on parity with Chrome.
Attachment #8765471 - Attachment is obsolete: true
Attachment #8767288 - Flags: checkin+
(In reply to Katie Broida [:ktbee] from comment #60)
> Created attachment 8767288 [details] [diff] [review]
> Version v4 for customizing Windows 10 start menu tile
> 
> I've noticed that Chrome has VisualElementsManifest.xml files that cover
> both the Windows 8 format and Windows 10. I've updated this patch to have
> both formats and bring it on parity with Chrome.

Katie, are you intending this patch to be checked in? checkin+ is normally used for patches that have been checked in. If you're requesting checkin, either use checkin?, or (more likely to succeed) add the 'checkin-needed' keyword in the 'keywords' field.
Flags: needinfo?(kbroida)
Flags: needinfo?(kbroida)
Attachment #8767288 - Flags: checkin+
(In reply to :Gijs Kruitbosch from comment #61)
> Katie, are you intending this patch to be checked in? checkin+ is normally
> used for patches that have been checked in. If you're requesting checkin,
> either use checkin?, or (more likely to succeed) add the 'checkin-needed'
> keyword in the 'keywords' field.

Yes, I was was trying to request checkin. Thank you for catching that and explaining the difference Gijs and thank you Jared for correcting it. Sorry for the confusion!
Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/fx-team/rev/d9b3b40f0e84
Improves the Windows 10 start menu tile by adding VisualElementsManifest files and larger icon images. r=glandium
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/d9b3b40f0e84
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
Blocks: 1283909
Depends on: 1284827
Depends on: 1284829
I suspect this patch broke the Nightly Win10 Start Tile, in that the background color is possibly wrong.

I believe it was 'grey' now its as shown, a light-blue ?  

Not sure that perhaps the background color for the Tile should perhaps match other tiles in a slightly darker blue perhaps >?
I had this too but I think this is a cached icon issue which should be fixed with bug 1284517. When I copy the whole FX folder to an other location and pin then it's firefox.exe to Start menu the icon is correct (the new icon and background).

As a workaround you can then change the path in this icon to the installed FX and amd delete then the new folder.
See Also: → 1286831
The Bug was about to Improve the Firefox start menu tile on Windows 8/10. I have seen the implementation on Latest Nightly 50.0a1 on Windows 10, 64 Bit.

This Bug is now verified as fixed on Latest Firefox Nightly 50.0a1

Build ID:  	20160728030208
User Agent:  	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
QA Whiteboard: [bugday-20160727]
Status: RESOLVED → VERIFIED
Depends on: 1297898
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: