Open Bug 445639 Opened 16 years ago Updated 2 years ago

Polish the Launch Application window


(Toolkit :: General, enhancement)





(Reporter: faaborg, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: polish, uiwanted, Whiteboard: [polish-easy][polish-visual][icon-namoroka][has wip patch, needs ui and icons][polish-p2])


(4 files)

-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
Forgot to include:

-Question dialog icon (48x48)
-Button says open instead of Ok
Dialog is cut off when you have selected to have large icons in Windows (done via the Display Properties dialog)
this bug is eligible for bug 462081
Keywords: polish
Whiteboard: [polish-easy][polish-visual]
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?"
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 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).
Ignore comment 5, I spoke too soon... I'll try to come up with something here soon enough.
Attached patch WIP ver. 1Splinter Review
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)?
Assignee: nobody → highmind63
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?
Here's a screen shot of what the dialog looks like now, I've updated it a bit locally.
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.
Keywords: uiwanted
For the case of the missing yahoo mail icon, perhaps there should be a default fallback icon for webapps?
>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.
Whiteboard: [polish-easy][polish-visual] → [polish-easy][polish-visual][icons-3.2]
Whiteboard: [polish-easy][polish-visual][icons-3.2] → [polish-easy][polish-visual][icon-3.2]
When bug 426727 gets fixed it will affect this bug as well as the launch application window uses a richlistbox.
Depends on: 426727
Whiteboard: [polish-easy][polish-visual][icon-3.2] → [polish-easy][polish-visual][icon-3.2][has wip patch, needs ui and icons]
Alex, any chance of getting these icons and spec'ing out the pinstripe/gnomestripe styles?
Since this is targeted for (I need to update my icon whiteboard terms), there is going to be some lag with getting the icons.
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.
Hardcoded references to /skin/ from code is bad anyway.

Use something like 
to define the icon to be used, when the system default doesn't result in setting the 'image' attribute...
See also:
for an example on how this is done for the favicon in the urlbar.
(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.
(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.
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.
Whiteboard: [polish-easy][polish-visual][icon-3.2][has wip patch, needs ui and icons] → [polish-easy][polish-visual][icon-namoroka][has wip patch, needs ui and icons][polish-p2]
Flags: wanted-firefox3.6?
I'd love to get some icons and/or a ui workup for Mac and Linux. That's really all this is waiting for.
Pushing out old bugs that I won't have time to actually get to. Feel free to use/extend any patches attached...
Assignee: highmind63 → nobody
Flags: wanted-firefox3.6?
blocking2.0: --- → ?
Component: File Handling → General
Product: Firefox → Toolkit
QA Contact: file.handling → general
blocking2.0: ? → ---
Blocks: 639215
It'd be great to improve this dialog, if someone could provide icons and design.

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


Flags: needinfo?(bgrinstead)

For future reference, this code lives in and can be opened via:

  • about:preferences -> Applications -> mailto -> Always Ask
  • load data:text/html,<a href="">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 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.

Flags: needinfo?(bgrinstead)
Severity: normal → S3

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.

Flags: needinfo?(dtownsend)
Severity: S3 → --
Type: defect → enhancement
Flags: needinfo?(dtownsend)
You need to log in before you can comment on or make changes to this bug.