Closed
Bug 183700
Opened 22 years ago
Closed 21 years ago
Text in cookie confirmation dialog doesn't wrap
Categories
(Core :: Networking: Cookies, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: zilla, Assigned: mvl)
References
()
Details
(Whiteboard: checkwin checklinux)
Attachments
(2 files)
650 bytes,
patch
|
Details | Diff | Splinter Review | |
5.27 KB,
image/png
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 When a site sets more than two cookies the text "The site www.example.com wants permission to set another cookie. You already have 2 cookies from this site. Do you want to allow it?" doesn't wrap, causing the dialog to stretch horizontally to fit the text. Given a long domain name, this dialog could stretch to wider than the screen width. This behaviour is new to 1.2, the text was wrapped in 1.0 and 1.1 so the dialog's width was constant. Possibly caused by the fix for bug 23508? The cookie details are restricted to fit in the window, but the dialog's main text isn't and can make it stretch arbitrarily wide (see second image at the URL above) Reproducible: Always Steps to Reproduce: 1. Ensure "Ask me before accepting a cookie" pref is enabled 2. Choose a site that sets more than two cookies (e.g. URL above) 3. Clear all existing cookies from that domain 4. Load the chosen URL Actual Results: The confirmation dialog changes width for each cookie. Expected Results: The dialog should have a fixed width and the text should be wrapped when it doesn't fit. Possibly related to one or more of bug 34200, bug 37690, bug 176634 ?
Comment 1•22 years ago
|
||
If this is indeed a regression caused by bug 23508, then this is unfortunate. My biggest concern about the patch for that bug was that it in no way affect the behavior for the user that doesn't want to see the cookie details (other than their seeing one additional button). Reassigning to mvl@shop-engine.nl who created that patch.
Assignee: morse → mvl
Comment 2•22 years ago
|
||
Morse: this did coincide with the checkin for 23508. I'm fairly certain I've seen this issue in another bug, but I'm unable to find it at the moment.
Assignee | ||
Comment 3•22 years ago
|
||
I had noticed the problem in bug 163350, there is a screenshot there (attachment 100591 [details]). This is a simple patch which sets a max-width on the box that contains the text. Style line copied from http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/commonDialog.xul#23
Updated•22 years ago
|
Attachment #108413 -
Flags: superreview?(blaker)
Attachment #108413 -
Flags: review?(morse)
Updated•22 years ago
|
Attachment #108413 -
Flags: review?(morse) → review+
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
win32 trunk build 2002122508, W2K Am I the only one with a dialog window that's not wide enough? Toggling the Details display corrects the dialog window width for that instance, but the next cookie dialog that displays is once again clipped.
Assignee | ||
Updated•22 years ago
|
Attachment #108413 -
Flags: superreview?(blaker) → superreview?(alecf)
Comment 5•22 years ago
|
||
it seems like the correct solution is to call sizeToContent() whenever the details are exposed, no? Otherwise, what do you do if the theme makes the font bigger, or adds images, etc..?
Assignee | ||
Comment 6•22 years ago
|
||
> it seems like the correct solution is to call sizeToContent() whenever the > details are exposed, no? Calling sizeToContent() doesn't fix the issue. It is already called when you press the show/hide details button. Pressing the button doesn't wrap the text. > Otherwise, what do you do if the theme makes the font > bigger, or adds images, etc..? As said, I copied the style line from commonDialog.xul. That means, that that kind of theme changes would break all dialogs. So this is a better solution than nothing, and it will not break themes.
Comment 7•22 years ago
|
||
the "because its done elsewhere" argument doesn't work here - there are bugs in mozilla, therefor we should check in more buggy code? I think not :) Anyhow, I guess I'd just like to hear from a xul expert on the proper thing. if sizeToContent() is broken, is there a bug on that? Have you tried setting off sizeToContent() from a 0 length timer? I understand this "fixes" the problem but its not worth introducing another bug just to fix this one. Who knows, maybe this will allow us to fix commonDialogs.xul?
Assignee | ||
Comment 8•22 years ago
|
||
please note that I am not trying to fix comment 4 / attachment 110216 [details] here. That is something with sizeToContent not working or some other problem. It is submitted as bug 187975. The underlying problem for the wide dialog is that there is no width set for dialogs in dialog.css or some other file. So they can grow as wide as they want. I think there should be some rule in dialog.css that gives standard dialogs a specified width. Special dialogs can overrule that.
Comment 9•22 years ago
|
||
Comment on attachment 108413 [details] [diff] [review] Set max-width I tell you what - I'm kicking off r=morse because I want an r= from a strong xul hacker.. when you get it, ask me again.. thanks!
Attachment #108413 -
Flags: superreview?(alecf)
Attachment #108413 -
Flags: review+
Comment 10•22 years ago
|
||
FYI, the change to common dialog was checked in (r=rjcm, a=jar) in Feb 2000. See bug 27732, and also http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF &root=/cvsroot&subdir=mozilla/xpfe/global/resources/content &file=commonDialog.xul&rev1=1.14&rev2=1.15
Comment 11•22 years ago
|
||
Quick recap: Text won't wrap without a horizontal constraint. Now in a browser, or in the preferences window, or other manually sized windows, this is not a problem because the window size constrains everything. As sizeToContent has no way to force the text to wrap, commonDialog.xul uses a max-width: 45em; hack.
Assignee | ||
Comment 12•22 years ago
|
||
Why don't we give dialog in general a width in a css file? That could give mac dialog a fixed width (bug 79623), and windows and linux dialog a maximum width. Maybe only for common dialogs, and dialog that have a special class, to be able to give other dialog greater width if required.
Comment 13•22 years ago
|
||
cc'ing jag (since he's a "strong xul hacker"). jag, what do you think? to my untrained eye, having a general max width for all dialogs, specified in CSS, sounds good - that way, we force designers to think about whether they need an exception, rather than just throwing in "width=<insert random number here>". waiting for jag to respond :)
Comment 14•22 years ago
|
||
repeating above request (since i forgot to add cc=jag before). jag, could you take a look at this?
Comment 15•22 years ago
|
||
This sounds good to me, but I wonder how many existing dialogs will be (negatively) impacted by this change. I assume that whoever wants to make this change will check all dialogs, and find a Netscape tree buddy to do the same. CC'ing hewitt for his opinion.
Reporter | ||
Comment 16•21 years ago
|
||
WFM in 1.4 - the new cookie dialog splits the offending text over two lines.
Reporter | ||
Comment 17•21 years ago
|
||
Resolving this as FIXED since a change in the cookie dialog has made this bug disappear.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 18•20 years ago
|
||
Mozilla 1.8a4. On Mac, this doesn't work. I'll muck w/ the other platforms tomorrow.
QA Contact: tever → benc
Whiteboard: checkwin checklinux
You need to log in
before you can comment on or make changes to this bug.
Description
•