Closed Bug 183700 Opened 22 years ago Closed 22 years ago

Text in cookie confirmation dialog doesn't wrap

Categories

(Core :: Networking: Cookies, defect)

x86
Windows 98
defect
Not set
trivial

Tracking

()

RESOLVED FIXED

People

(Reporter: zilla, Assigned: mvl)

References

()

Details

(Whiteboard: checkwin checklinux)

Attachments

(2 files)

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 ?
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
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.
Attached patch Set max-widthSplinter Review
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
Attachment #108413 - Flags: superreview?(blaker)
Attachment #108413 - Flags: review?(morse)
Attachment #108413 - Flags: review?(morse) → review+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached image clipped cookie dialog
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.
Attachment #108413 - Flags: superreview?(blaker) → superreview?(alecf)
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..?
> 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.
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?
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 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+
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
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.
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.
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 :)
repeating above request (since i forgot to add cc=jag before). jag, could you take a look at this?
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.
WFM in 1.4 - the new cookie dialog splits the offending text over two lines.
Resolving this as FIXED since a change in the cookie dialog has made this bug disappear.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: