Closed Bug 183700 Opened 22 years ago Closed 21 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: 21 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: