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)
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 |
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.
Reporter | ||
Updated•9 years ago
|
Whiteboard: [qx][onboarding]
Comment 1•9 years ago
|
||
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.
Reporter | ||
Comment 3•9 years ago
|
||
(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)
Comment 4•8 years ago
|
||
Updated•8 years ago
|
Blocks: qx-onboarding
Updated•8 years ago
|
Mentor: jaws
Whiteboard: [qx][onboarding] → [qx][onboarding][outreachy-12]
Updated•8 years ago
|
Points: --- → 8
Updated•8 years ago
|
Summary: Improve the Firefox start menu tile on Windows 10 → Improve the Firefox start menu tile on Windows 8/10
Comment 6•8 years ago
|
||
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.
Comment 7•8 years ago
|
||
Stephen, how 'simple' is it to provide branding .ico's in reverse order?
Flags: needinfo?(shorlander)
Comment 8•8 years ago
|
||
(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.
Updated•8 years ago
|
Flags: needinfo?(shorlander)
Reporter | ||
Comment 9•8 years ago
|
||
(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.
Comment 10•8 years ago
|
||
(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.
Comment 11•8 years ago
|
||
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.
Reporter | ||
Comment 12•8 years ago
|
||
(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.
Comment 13•8 years ago
|
||
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
Comment 14•8 years ago
|
||
(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?
Comment 15•8 years ago
|
||
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
Updated•8 years ago
|
Priority: -- → P3
Comment 16•8 years ago
|
||
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)
Reporter | ||
Comment 17•8 years ago
|
||
(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.
Reporter | ||
Comment 18•8 years ago
|
||
Background color should be: #0996f8 Show the app name App name color: White
Flags: needinfo?(mverdi)
Reporter | ||
Comment 19•8 years ago
|
||
Comment 20•8 years ago
|
||
Verdi, we will need colors and icons for DevEdition and Nightly as well.
Flags: needinfo?(mverdi)
Reporter | ||
Comment 21•8 years ago
|
||
Attachment #8751408 -
Attachment is obsolete: true
Flags: needinfo?(mverdi)
Reporter | ||
Comment 22•8 years ago
|
||
Attachment #8751407 -
Attachment is obsolete: true
Reporter | ||
Comment 23•8 years ago
|
||
Reporter | ||
Comment 24•8 years ago
|
||
Reporter | ||
Comment 25•8 years ago
|
||
Reporter | ||
Comment 26•8 years ago
|
||
Reporter | ||
Comment 27•8 years ago
|
||
Ok, all three tiles get: Show the app name App name color: White Release background: #0996f8 Dev Edition & Nightly background: #14171a
Comment 28•8 years ago
|
||
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)
Comment 29•8 years ago
|
||
(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?
Reporter | ||
Comment 30•8 years ago
|
||
(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
Reporter | ||
Comment 31•8 years ago
|
||
Attachment #8751856 -
Attachment is obsolete: true
Reporter | ||
Comment 32•8 years ago
|
||
Attachment #8751857 -
Attachment is obsolete: true
Reporter | ||
Comment 33•8 years ago
|
||
Attachment #8751858 -
Attachment is obsolete: true
Reporter | ||
Comment 34•8 years ago
|
||
Attachment #8751859 -
Attachment is obsolete: true
Reporter | ||
Comment 35•8 years ago
|
||
Attachment #8751860 -
Attachment is obsolete: true
Comment 36•8 years ago
|
||
(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)
Comment 37•8 years ago
|
||
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.)
Assignee | ||
Comment 38•8 years ago
|
||
Yup! Sounds good, Jared. I'll work on this one next.
Flags: needinfo?(kbroida)
Updated•8 years ago
|
No longer blocks: qx-onboarding
Assignee | ||
Comment 39•8 years ago
|
||
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)
Comment 40•8 years ago
|
||
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 41•8 years ago
|
||
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)
Assignee | ||
Comment 42•8 years ago
|
||
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)
Comment 43•8 years ago
|
||
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)
Comment 44•8 years ago
|
||
(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.
Comment 45•8 years ago
|
||
(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)
Assignee | ||
Comment 47•8 years ago
|
||
(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)
Comment 48•8 years ago
|
||
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)
Assignee | ||
Comment 49•8 years ago
|
||
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
Comment 50•8 years ago
|
||
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 51•8 years ago
|
||
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 52•8 years ago
|
||
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 53•8 years ago
|
||
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)
Assignee | ||
Comment 54•8 years ago
|
||
(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)
Assignee | ||
Comment 55•8 years ago
|
||
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)
Assignee | ||
Comment 56•8 years ago
|
||
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 57•8 years ago
|
||
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+
Assignee | ||
Comment 58•8 years ago
|
||
(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/ ?
Comment 59•8 years ago
|
||
(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.
Assignee | ||
Comment 60•8 years ago
|
||
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+
Comment 61•8 years ago
|
||
(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)
Updated•8 years ago
|
Keywords: checkin-needed
Updated•8 years ago
|
Flags: needinfo?(kbroida)
Attachment #8767288 -
Flags: checkin+
Assignee | ||
Comment 62•8 years ago
|
||
(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!
Comment 64•8 years ago
|
||
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
Comment 65•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d9b3b40f0e84
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox50:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
Comment 66•8 years ago
|
||
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 >?
Comment 67•8 years ago
|
||
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.
Comment 68•8 years ago
|
||
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]
Assignee | ||
Updated•8 years ago
|
Status: RESOLVED → VERIFIED
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•