"Launch Application" dialog clips buttons on bottom

VERIFIED FIXED in Firefox 3 beta1

Status

()

Firefox
General
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: abillings, Assigned: sdwilsh)

Tracking

({polish})

Trunk
Firefox 3 beta1
polish
Points:
---
Bug Flags:
blocking-firefox3 +
in-testsuite -
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
The new "Launch Application" dialog is now clipping the "cancel" and "ok" buttons at its default size.

See attached image.

This was found in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007091704 Minefield/3.0a8pre.
(Reporter)

Comment 1

11 years ago
Created attachment 281400 [details]
The dialog.
This was also mentioned in bug 389705, but I guess it isn't really quite the same bug. Might be fixed by a patch there, though.
Depends on: 389705

Updated

11 years ago
Flags: blocking-firefox3?

Comment 3

11 years ago
Created attachment 283256 [details]
Launch Application dialog has bottom and right cut-off

I've also got this running on Ubuntu 7.10 Beta and Gnome 2.20
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007100209 Minefield/3.0a9pre ID:2007100209
Flags: blocking-firefox3? → blocking-firefox3+
Keywords: polish

Updated

11 years ago
Target Milestone: --- → Firefox 3 M9

Updated

11 years ago
Assignee: nobody → comrade693+bmo
Seems to also be mentioned in bug 394258.

Comment 5

11 years ago
dupe/similar bug 394711 ?
(In reply to comment #5)
> dupe/similar bug 394711 ?

Yours is a duplicate, but of which bug (and the other will be duped to _it_), I'm not sure... 

(Assignee)

Updated

11 years ago
Duplicate of this bug: 394711
(Assignee)

Comment 8

11 years ago
Created attachment 284811 [details] [diff] [review]
v1.0

This basically does what Bug 389705 was going to do (that's targeting M10, this is M9, so let's fix it here).  If mfinkle could take a quick look-over, that'd be great.
Attachment #284811 - Flags: review?(mark.finkle)
Attachment #284811 - Flags: review?(gavin.sharp)
(Assignee)

Updated

11 years ago
Blocks: 389705
No longer depends on: 389705

Updated

11 years ago
OS: Mac OS X → All
Hardware: Macintosh → All
Comment on attachment 284811 [details] [diff] [review]
v1.0


>-<!ENTITY window.width "320">
>-<!ENTITY window.height "250">
>+<!ENTITY window.EMwidth "26em">
>+<!ENTITY window.EMheight "26em">

EMwidth & EMheight? not "-" worthy but I'd drop the "EM". We don't use "PX" prefixes

> <dialog id="handling"
>         ondialogaccept="return dialog.onAccept();"
>         onload="dialog.initialize();"
>-        width="&window.width;" height="&window.height;"
>+        style="min-width: &window.EMwidth;; min-height: &window.EMheight;;"
>         persist="width height screenX screenY sizemode"
>         xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

Why are we persisting "sizemode" ? I yanked it from my patch.

r=mfinkle with those answered
Attachment #284811 - Flags: review?(mark.finkle) → review+
I'll remove the relevant changes from bug 389705, since they are handled here. Bug 389705 will still handle other stuff.
Comment on attachment 284811 [details] [diff] [review]
v1.0

I agree with mfinkle on both points - the names don't need "EM", and persisting sizemode doesn't make sense for a dialog.
Attachment #284811 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 12

11 years ago
Alright, but it's my understanding that we need to be changing the name of strings if we change them.  I would think that this applies to this especially because we want this in em's now (and if a locale doesn't update it and had something similar to before, they'll have a really really big dialog).
(In reply to comment #12)
> Alright, but it's my understanding that we need to be changing the name of
> strings if we change them.

Ah, yes. Good point. I don't know how likely these are to have already been translated, but better to be safe than sorry.
(Assignee)

Comment 14

11 years ago
in that case, suggestions for the new name, or is this sufficient?
Those are fine.
Although, maybe emWidth to avoid it being confused with EM (Extension Manager)? Doesn't matter much either way :)

Updated

11 years ago
Whiteboard: [has patch][has reviews]

Updated

11 years ago
Target Milestone: Firefox 3 M9 → Firefox 3 M10
(Assignee)

Comment 17

11 years ago
Created attachment 286222 [details] [diff] [review]
v1.1

for checkin.

Addresses review comments.  This won't fix it for people who have already opened the window (because of the persists stuff), but any first timers to it and any new profiles will work out correctly.

This would be nice to have for the beta, and should be low risk.
Attachment #284811 - Attachment is obsolete: true
Attachment #286222 - Flags: approvalM9?
Attachment #286222 - Attachment is patch: true
Attachment #286222 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Updated

11 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M9
(Assignee)

Updated

11 years ago
Duplicate of this bug: 394258
Comment on attachment 286222 [details] [diff] [review]
v1.1

(Please leave the target milestone alone next time!)
Attachment #286222 - Flags: approvalM9?
Attachment #286222 - Flags: approvalM9+
Attachment #286222 - Flags: approval1.9+
(Assignee)

Comment 20

11 years ago
Checking in toolkit/locales/en-US/chrome/mozapps/handling/handling.dtd;
new revision: 1.2; previous revision: 1.1
Checking in toolkit/mozapps/handling/content/dialog.xul;
new revision: 1.4; previous revision: 1.3
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: in-testsuite-
Flags: in-litmus?
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Whiteboard: [has patch][has reviews]
I think min-width:&window.emWidth;em; or min-width:&window.styleWidth;; would have made more sense. Oh well ...

Comment 22

11 years ago
hrm, using em for width is suboptimal, you probably should have used ch units instead, which really base on character width, while em bases on line height (and is fine for height because of that).
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre and  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre. I verified by launching some links from mail.

As a side note, when I use Thunderbird trunk on the Mac I get the dialog when the pref is set to ask. When I use Thunderbird branch, no matter what the pref is set to on trunk, I don't get the ask dialog. Not sure if this is expected, I can file a spinoff bug for this.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.