Closed Bug 62955 Opened 24 years ago Closed 24 years ago

most dialog boxes sized too small

Categories

(Core :: XUL, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: tracy, Assigned: rpotts)

References

()

Details

(Keywords: smoketest)

Attachments

(2 files)

seen commercial builds:

linux 2000-12-15-06-Mtrunk
mac 2000-12-15-08-Mtrunk

various pop up dialogue boxes are sized too small to encompass all the 
information to be displayed. On the linux build several warning dialogues were 
truncated but not to the point that you couldn't click on a button at the bottom 
of the dialogue.  However, on the Mac build, the warning dialogue that pops up 
when attempting to open a secure site is sized such that the okay button is 
completely missing and thus the dialogue cannot be dismissed.  The only way out 
is to force kill the application and relaunch.
Keywords: smoketest
I don't understand why this is in UI:DF.  Sending to XPT for lack of a better 
place, cc'ing danm.

I don't think this needs to be a blocker.  Dismissing the dialog via 
enter/return, escape, or tab and then space doesn't work?
Assignee: hangas → trudelle
Component: User Interface: Design Feedback → XP Toolkit/Widgets
QA Contact: mpt → jrgm
this bugreport is duplicate because it was mentioned
several times today. please pass through the buglist
here. its all the same..
Oh...okay...hitting enter does dismiss this dialogue.
but this horribly unstylish and someone if doesn't know the okay button exists, 
it would be quite puzzling when these windows do appear.

anyway, reducing severity 
Thanks, Tracy.

(really reducing severity...)
Severity: blocker → critical
->danm p2/moz0.8
Assignee: trudelle → danm
Priority: P3 → P2
Target Milestone: --- → mozilla0.8
*** Bug 62932 has been marked as a duplicate of this bug. ***
*** Bug 63028 has been marked as a duplicate of this bug. ***
*** Bug 63063 has been marked as a duplicate of this bug. ***
This also happens in 2000121608 on win98 SE with username/password dialog boxes.
The password textbox is cut off by this. Really ugly, and anyone who doesn't
know to tab to get to the pw field is S.O.L.
And for the "Windows integration" box you get at start you can't even read the
whole statement that you have to accept or cancel. 
*** Bug 63113 has been marked as a duplicate of this bug. ***
Adding CC, I just added a screen-shot attachment, as well.
Blocks: 63110
fwiw, I think the problem is in the c++ backend for a dialog interface.
*** Bug 63123 has been marked as a duplicate of this bug. ***
*** Bug 63150 has been marked as a duplicate of this bug. ***
*** Bug 63169 has been marked as a duplicate of this bug. ***
I've seen this in a lot of places too. Like the "Download Headers" window, when
it asks how many headers you want to download.
*** Bug 55838 has been marked as a duplicate of this bug. ***
*** Bug 63183 has been marked as a duplicate of this bug. ***
Keywords: mostfreq, nsbeta1
*** Bug 63201 has been marked as a duplicate of this bug. ***
*** Bug 63110 has been marked as a duplicate of this bug. ***
*** Bug 63218 has been marked as a duplicate of this bug. ***
*** Bug 63192 has been marked as a duplicate of this bug. ***
*** Bug 63189 has been marked as a duplicate of this bug. ***
*** Bug 63208 has been marked as a duplicate of this bug. ***
Seeing this on:
Platform: PC
OS: Windows 98
Mozilla Build: #2000121804 M18 Trunk Build


Happened to me on the "Reload Form?" Dialog box.
*** Bug 63250 has been marked as a duplicate of this bug. ***
*** Bug 63254 has been marked as a duplicate of this bug. ***
*** Bug 63253 has been marked as a duplicate of this bug. ***
*** Bug 63269 has been marked as a duplicate of this bug. ***
I'm marking this a blocker since I can't resize my imap password dialog and
can't read mail.
Severity: critical → blocker
As someone pointed out I can hit return.  Duh.
Severity: blocker → critical
Bug 60509 cannot be verified with the latest nightlies because of this bug.
Marking as a blocker.
Blocks: 60509
No longer blocks: 63110
*** Bug 63302 has been marked as a duplicate of this bug. ***
*** Bug 63305 has been marked as a duplicate of this bug. ***
*** Bug 63326 has been marked as a duplicate of this bug. ***
Just looked through
http://bonsai.mozilla.org/showcheckins.cgi?&treeid=SeaMonkey&batchid=421
(last checkins for 2000-12-15 builds) and saw some changes to
ns<foo>Window.[cpp|h] files by danm@netscape.com
Could this be related to that checkins?
(Sorry, I don't understand C code so I didn't really look at the details of the
checkins)
More specifically, this checkin was made by danm@netscape.com:

http://bonsai.mozilla.org/cvsview2.cgi?
diff_mode=context&whitespace_mode=show&root=&subdir=mozilla/xpfe/appshell/src&co
mmand=DIFF_FRAMESET&root=&file=nsXULWindow.cpp&rev1=1.54&rev2=1.55

It changes some dialog stuff in nsXULWindow.cpp 
ARG. They could be. They *really* shouldn't be.

danm: are we persisting sizing from one dialog to another?

All: you can testcase this, just find a small or a large dialog and use it before you use some other one. Describe the outcome here.
Using Win98 2000121804 and (prev to using that) 200012190?, it seemed that the
dialogue box size was, indeed, persistent. Seen on several size dialogs, all
seemed to be the same size (security warning, http auth, image/cookie warning).
  I doubt it was my window state checkin that made this happen. That checkin does 
mean that these dialogs get an extra "show yourself normally" call, but that 
should be harmless. I'm not doing anything new with the size; just the min/max 
state.
  I can't especially make this problem happen on my machine. The profile 
migration dialog looks fine to me, and ... this is embarrassing ... I can't 
figure out how to get the security warning dialog. I've tried setting those 
preferences to true, but I'm not getting them. The closest I've been able to get 
is in the "Password manager can remember this logon" dialog, which cuts off just 
the lower half of my OK/Cancel buttons on my machine.
  My first culprit for this situation would be rpotts' checkin on 2000/12/14 to 
nsWebShellWindow and nsBrowserInstance, which was not unlikely to cause some 
document end load timing problems. This is supported by the fact that my build, 
which generally behaves but does cut off half the buttons on that password 
manager dialog, no longer has that problem if I back out rpotts' checkin.
  Can any of you folks who are having this problem do a build with that checkin 
backed out (and again with my checkin backed out), to help pin down the problem? 
Again, rpotts' checkin seems the culprit as near as I can tell, though I can't 
really see the problem.
*** Bug 63363 has been marked as a duplicate of this bug. ***
D'oh! I just filed a duplicate of this... I'll close it as a dup and get the
info here. One thing for starters: try javascript:alert("foo\n\n\nbar"). That
should demonstrate the problem. Also try resizing that window (on linux, where
it's allowed) and see the garbage it gives you.

-dr
haha, jrgm beat me to it. the ironic thing is that i couldn't find any
duplicates of this when i looked on bugzilla. i'm retarded. anyway, here's what
i wrote when opening the bug:

---

Many dialogs (perhaps all the commonDialogs?) come up sized all the same, all
too small for their content. This includes password entry dialogs, "are you
sure" dialogs, javascript:alert and javascript:prompts, etc.

Also, on linux (where you're allowed to resize these dialogs) when you try to
resize them, you get garbage at the bottom of the dialogs, as if they didn't
know how to resize themselves at all.

This is a recent regression -- I first noticed it around Dec. 14 or so.

Assigning to danm for now... I'll keep snooping too.
Summary: pop up warning dialogue boxes sized too small → most dialog boxes sized too small
*** Bug 63361 has been marked as a duplicate of this bug. ***
  Alright, now I'm seeing the problem. I'm seeing it in javascript alerts. The 
detail people seem to be leaving out is that you need to make the alert text 
several lines tall. Typing this:
  javascript:alert('stumpy\n\n\nuses\nhedge\nclippers')
into the URL bar shows a clipped alert.

  Now that I can reproduce the problem reliably, I can say that backing out my 
changes fingered above doesn't fix it, while backing out rpotts' from the same 
day does.
  His are changes we want in the long run, though. Punting the bug over to him 
for whatever comes next.
*** Bug 63436 has been marked as a duplicate of this bug. ***
*** Bug 63440 has been marked as a duplicate of this bug. ***
*** Bug 63441 has been marked as a duplicate of this bug. ***
*** Bug 63461 has been marked as a duplicate of this bug. ***
*** Bug 63461 has been marked as a duplicate of this bug. ***
*** Bug 63461 has been marked as a duplicate of this bug. ***
*** Bug 63503 has been marked as a duplicate of this bug. ***
I don't know what rpotts' changes were, but can't they be backed out at least
until he finds the problem? This makes mozilla really difficult to use for me.
*** Bug 63364 has been marked as a duplicate of this bug. ***
When I backed out in my tree the checkins I mentioned above, this bug was not
fixed.  Did I misunderstand which checkins danm backed out?
I've just checked in a fix to nsDocLoader.cpp for this one...
 
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 63101 has been marked as a duplicate of this bug. ***
veified fixed on commercial builds:

windows 2000-12-26-06-Mtrunk
linux 2000-12-26-06-Mtrunk
Status: RESOLVED → VERIFIED
*** Bug 63758 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: