445639 - Polish the Launch Application window

Status: NEW

(Toolkit :: General, enhancement)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

-Spacing is 2 pixels greater on the right side
-There aren't any icons for the applications
-The application text is bold
-The text at the top of the window should read "This Web site would like to send information to an application" since the window might be invoked in a way that does not involve a hyperlink.
-Font color of URLs for mailto handlers do not change to a more readable color when they are selected
-"Choose an Application" row is not as tall as application rows
-Selecting "Choose an Application..." should launch the open window, not an additional button, the text should have an ellipsis
-The text "Choose an Application..." should be aligned to the titles of applications, give it the same icon used for the applications prefpane

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Current interface and Mockup

Forgot to include:

-Question dialog icon (48x48)
-Button says open instead of Ok

Comment 2

[José Jeria]

Attachment: Dialog is cut-off when using large icons on Windows

Dialog is cut off when you have selected to have large icons in Windows (done via the Display Properties dialog)

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

this bug is eligible for bug 462081

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

A few additional details:

selecting choose application should launch the open dialog so the user can select an application.

change message the text from "This Web site would like to send information in application" to "What application would you like to use?"

Comment 5

[Nochum Sossonko [:Natch]]

I'm not sure I understand the intent here 100%, the dialog your talking about is the one that pops up when you click on a link that's set to "always ask" (and is a registered protocol), it already displays images when possible (e.g. gmail icon for the mailto protocol), the problem is for local applications that handle these protocols I can't really figure out how to get there image information. For the other, similar dialogs like http://mxr.mozilla.org/mozilla-central/source/toolkit/components/apppicker/content/appPicker.xul already have this information but that seems to be very different because they're handling with an nsILocalHandlerApp whereas here it seems to be an nsIWebHandlerApp or nsIDbusHandlerApp both of which don't have this information.

I think, to simplify this bug, the styling stuff should be done here (although this seems to be Vista only, xp, linux and mac don't really have that lightish-blue look).

Comment 6

[Nochum Sossonko [:Natch]]

Ignore comment 5, I spoke too soon... I'll try to come up with something here soon enough.

Comment 7

[Nochum Sossonko [:Natch]]

Attachment: WIP ver. 1

This is the first version of the patch, some specs still remain but feedback would be greatly appreciated. Note, two images will have to be moved to toolkit and referenced from there, unless I should duplicate them? or is it ok to reference a browser image in toolkit (I suspect not)?

Comment 8

[Nochum Sossonko [:Natch]]

Alex, I haven't really done anything about pinstripe and gnomestripe because I'm not sure what the look should be like, can you detail that a bit? Also, is there supposed to be a different look for XP?

Comment 9

[Nochum Sossonko [:Natch]]

Attachment: What it looks like so far

Here's a screen shot of what the dialog looks like now, I've updated it a bit locally.

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

Looks like it is coming along well.  Vista and XP can both use the same dialog design.  I'm adding uiwanted to spec out the design on OS X.

Comment 11

[Nochum Sossonko [:Natch]]

For the case of the missing yahoo mail icon, perhaps there should be a default fallback icon for webapps?

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

>For the case of the missing yahoo mail icon, perhaps there should be a default
>fallback icon for webapps?

Yep, I've listed icons for both generic desktop applications and generic web applications (at 16x16 and 32x32) for production for 3.2 on all platforms.

Comment 13

[Nochum Sossonko [:Natch]]

When bug 426727 gets fixed it will affect this bug as well as the launch application window uses a richlistbox.

Comment 14

[Nochum Sossonko [:Natch]]

Alex, any chance of getting these icons and spec'ing out the pinstripe/gnomestripe styles?

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

Since this is targeted for 3.5.next (I need to update my icon whiteboard terms), there is going to be some lag with getting the icons.

Comment 16

[Dão Gottwald [:dao]]

Comment on attachment 363649 [details] [diff] [review]
WIP ver. 1

>--- a/toolkit/mozapps/handling/content/dialog.js
>+++ b/toolkit/mozapps/handling/content/dialog.js
>@@ -67,6 +67,8 @@ const Ci = Components.interfaces;
> const Ci = Components.interfaces;
> const Cr = Components.results;
> 
>+const ICON_URL_APP = "chrome://browser/skin/preferences/application.png";

References to browser/ in toolkit code = bad. I realize it's a WIP, though. Just saying.

Comment 17

[Alfred Kayser]

Hardcoded references to /skin/ from code is bad anyway.

Use something like 
#app-image:not(image){list-style-image:url("chrome://browser/skin/preferences/application.png")}
to define the icon to be used, when the system default doesn't result in setting the 'image' attribute...

Comment 18

[Alfred Kayser]

See also:
http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#1131
for an example on how this is done for the favicon in the urlbar.

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #16)
> 
> References to browser/ in toolkit code = bad. I realize it's a WIP, though.
> Just saying.

In general, a bunch of the content-handling code that currently lives in browser/ wants to move to toolkit, so this may or may not be fixable without dealing with that issue more generally.  It's possible that could happen piecemeal in bugs like this one, but there is a bug filed on the bigger more general issue as well.

Comment 20

[Nochum Sossonko [:Natch]]

(In reply to comment #16)
> References to browser/ in toolkit code = bad. I realize it's a WIP, though.
> Just saying.

I planned on moving it once this bug was further along, I just didn't want to have to go through the tree and fix every reference to that image. I created the WIP just to throw up a screenshot so that ux could see what it looks like. Alternatively, I can copy the pictures to toolkit, but that feels like a huge waste. I will continue updating this patch once there are icons in place, plus some sort of idea of what linux and mac are supposed to look like. Also, my richlistitem hack will be obsolete when bug 426727 lands, so I'll have to update that as well.

(In reply to comment #17 and #18)
I'll look into that, thanks.

Comment 21

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug's priority relative to the set of other polish bugs is:
P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable.

Still a lot of easily noticeable polish work for us to do on this dialog.

Comment 22

[Nochum Sossonko [:Natch]]

I'd love to get some icons and/or a ui workup for Mac and Linux. That's really all this is waiting for.

Comment 23

[Nochum Sossonko [:Natch]]

Pushing out old bugs that I won't have time to actually get to. Feel free to use/extend any patches attached...

Comment 24

[Marco Castelluccio [:marco]]

It'd be great to improve this dialog, if someone could provide icons and design.

Comment 25

[Sebastian Zartner [:sebo]]

Brian, should this old bug be reused to replace the XUL from this dialog by something new or should a new one be created?

Sebastian

Comment 26

[Brian Grinstead [:bgrins]]

For future reference, this code lives in https://searchfox.org/mozilla-central/source/toolkit/mozapps/handling/content/dialog.xul and can be opened via:

• about:preferences -> Applications -> mailto -> Always Ask
• load data:text/html,<a href="mailto:[e-mail]">email</a> and click on the link

(In reply to Sebastian Zartner [:sebo] from comment #25)

Brian, should this old bug be reused to replace the XUL from this dialog by something new or should a new one be created?

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1585482 to stop relying on <xul:dialog> as a root element, which should unblock reliance on a root dialog element specifically (it would most likely be migrated to something like html:moz-dialog after that but not necessarily change the Custom Element implementation in a major way).

As for the contents of the dialog, it looks like this is using <xul:richlistbox>, <xul:button>, etc. We ultimately want to move these to HTML elements (meta: Bug 1563415), but there's no need to do it individually for small documents because like de-XBL the plan is to migrate these elements tree-wide one at a time. So if someone wants to take this, they could polish up the existing document without worrying about a rewrite. If there are individual places where this seems hard to do with the current set of XUL widgets let me know so we can see if we should prioritizing some of that metabug's work ahead of others.

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.