Closed
Bug 183700
Opened 22 years ago
Closed 22 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•22 years ago
|
||
WFM in 1.4 - the new cookie dialog splits the offending text over two lines.
Reporter | ||
Comment 17•22 years ago
|
||
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
Comment 18•21 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
•