Closed Bug 404408 Opened 17 years ago Closed 17 years ago

"send link" dialog size cuts off ok/cancel button

Categories

(Firefox :: General, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: chofmann, Assigned: dao)

Details

(Keywords: qawanted)

Attachments

(2 files)

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-IN; rv:1.9b2pre) Gecko/2007111705 Minefield/3.0b2pre and earlier builds visit a web page file | send link attachment shows how the dialog size is not correct and ok/cancel buttons are cut off and the dialog look a bit ugly.
Flags: blocking-firefox3?
Attached image dialog size is off
or I guess the [ok] [cancel] buttons could be moved up and in a bit to fix this..
this is strange. with a clean profile the dialog looks ok. wonder how many other might be affected by something in there profile that causes the size to be off?
dougt says he has seen this on mac as well.
I don't have any addons installed in minefield, so I don't think and add-ons or a theme is causing the dialog size to be different in my old profile and a new clean one. I do have a pretty full bookmark toolbar on the old profile, but starting from a clean profile, and adding a bunch of bookmarks to fill up and overflow the bookmark toolbar didn't cause the send link dialog to start looking wrong.
Dan: pretty sure that this is a dupe against something that you're already handling; please resolve.
Assignee: nobody → dmose
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P3
Whiteboard: DUPEME
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
this was marked a dup of bug 389705 and sounded like it might be fixed when that bug was fixed, but I still see the problem. opening.
Resolution: DUPLICATE → FIXED
its pretty ugly, and something that seems like it might be easly to polish. nominating for p1, or p2.
Priority: P3 → P1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
With a few exceptions, I'm mostly focused on MailCo-related hacking now. Reassigning a bunch of bugs to default component owners. I'm happy to help with brainstorming/advice as needed, however. Search for the string MAILMONKEY to delete any bugmail generated by this change.
Assignee: dmose → nobody
Status: REOPENED → NEW
Is this still only something that happens on dirty profiles? Is it only if you're a previous trunk user? If its crufty data because we're reusing a window name, its an easy fix, IMO.
Priority: P1 → P2
Magic 8-ball says.. dao
Assignee: nobody → dao
Chris, have you ever resized that dialog? Are there persisted dimensions for it in localstore.rdf?
Keywords: qawanted
I suspect that the content consumed less space once and that the dialog has been resized at that time. This wouldn't be a blocker, since the dialog is new in 1.9. It could be worked around by changing the id of the dialog element. (In reply to comment #11) > If its crufty data because we're reusing a window name, its an easy fix, IMO. The window doesn't have a name. In localstore.rdf, it's identified by the chrome URI and the id of the dialog element.
I don't ever recall resizing the window some time long ago, but it's possible. Your explaination of a smaller dialog when things landed earlier in 1.9 makes sense, and would mean the number of people affected by this bug is limited to a smallish population of early fx3 alpha users. If I "file | send link" to bring up the dialog on my old profile, then resize the dialog to something that fits all the choices, then yes, it starts working fine from then on. At a minimum, this could be offered as the work around to getting things looking pretty. sounds like it might be ok to not do much with this bug if there isn't something clean and easy to force the dialog window size. that might also have localization impact if a local has resized the window...
(In reply to comment #15) > If I "file | send link" to bring up the dialog on my old profile, then resize > the dialog to something that fits all the choices, then yes, it starts working > fine from then on. At a minimum, this could be offered as the work around to > getting things looking pretty. Does this mean that this doesn't work with your current profile? That is, if you resize the window, it still won't fit the next time you open it?
no, what ever resize I do on the window is preserved next time I open. If I resize to fit, then it works fine for me.
I did some testing with alpha 8 and a current trunk build and couldn't reproduce something wrong. In alpha 8, the dialog was too small (bug 389705), and resizing it to make it fit made it fit on trunk as well. If I didn't resize it, the correct dimensions of a fresh profile kicked in on trunk automatically (since alpha 8 didn't store anything).
Status: NEW → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: