Edit Card dialog sizes itself incorrectly

VERIFIED FIXED in M11

Status

defect
P1
major
VERIFIED FIXED
20 years ago
15 years ago

People

(Reporter: scottputterman, Assigned: hangas)

Tracking

Trunk
All
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PR1])

Open the Address Book and bring up Edit Card dialog (or the New Card dialog).
Notice that instead of seeing the tabs with the correct tab's property page
showing, you instead see what looks to be about a 10px high border followed by
the OK and Cancel buttons.

It looks like this dialog isn't sizing itself properly.

Lisa and Paul, please update this bug as to whether you consider this a blocker
for this morning's builds.
Severity: normal → critical
QA Contact: lchiang → esther
Esther - do you consider this a blocker?  If so, mark as such.
Severity: critical → blocker
Yes, with the 19990726 build this bug is a blocker.  I can't create a New Card
or edit one.  Everything is swished up to the top of the dialog so I can't
access the tabs.  This is not how it was on Friday 7/23, however in Friday's
build the look of the dialog changed from the previous version on 7/21 with
larger than usual text fields and an overall unpolished UI look, but I could
test the functionality.
Target Milestone: M9
ok, if I poke the editcardDialog.xul, I can get something to show up.

Perhaps this can help hyatt / evaughn track down the bustage.

Index: editcardDialog.xul
===================================================================
RCS file: /cvsroot/mozilla/mailnews/addrbook/resources/content/editcardDialog.xu
l,v
retrieving revision 1.5
diff -p -r1.5 editcardDialog.xul
*** editcardDialog.xul  1999/07/19 21:43:23     1.5
--- editcardDialog.xul  1999/07/26 18:50:33
***************
*** 12,25 ****
                onload="OnLoadEditCard()"
                class="dialog"
                width="400" height="600"
!               style="width:100%; height:100%; padding:0px"
                align="vertical">

        <html:script language="JavaScript" src="chrome://addressbook/content/edi
tcard.js"/>


        <!-- Results pane -->
!       <html:iframe flex="100%"
                                 name="editcard"
                                 src="chrome://addressbook/content/editcard.xul"
/>

--- 12,25 ----
                onload="OnLoadEditCard()"
                class="dialog"
                width="400" height="600"
!               style="width:100%; height:100%"
                align="vertical">

        <html:script language="JavaScript" src="chrome://addressbook/content/edi
tcard.js"/>


        <!-- Results pane -->
!       <html:iframe style="width:300px; height:500px"
                                 name="editcard"
                                 src="chrome://addressbook/content/editcard.xul"
/>
ok, if I poke the editcardDialog.xul, I can get something to show up.

Perhaps this can help hyatt / evaughn track down the bustage.

Index: editcardDialog.xul
===================================================================
RCS file: /cvsroot/mozilla/mailnews/addrbook/resources/content/editcardDialog.xu
l,v
retrieving revision 1.5
diff -p -r1.5 editcardDialog.xul
*** editcardDialog.xul  1999/07/19 21:43:23     1.5
--- editcardDialog.xul  1999/07/26 18:50:33
***************
*** 12,25 ****
                onload="OnLoadEditCard()"
                class="dialog"
                width="400" height="600"
!               style="width:100%; height:100%; padding:0px"
                align="vertical">

        <html:script language="JavaScript" src="chrome://addressbook/content/edi
tcard.js"/>


        <!-- Results pane -->
!       <html:iframe flex="100%"
                                 name="editcard"
                                 src="chrome://addressbook/content/editcard.xul"
/>

--- 12,25 ----
                onload="OnLoadEditCard()"
                class="dialog"
                width="400" height="600"
!               style="width:100%; height:100%"
                align="vertical">

        <html:script language="JavaScript" src="chrome://addressbook/content/edi
tcard.js"/>


        <!-- Results pane -->
!       <html:iframe style="width:300px; height:500px"
                                 name="editcard"
                                 src="chrome://addressbook/content/editcard.xul"
/>
Priority: P3 → P1
Whiteboard: BLOCKER CONFIRMED
Seth,

Assuming I'm applying your changes correctly, I'm not seeing any difference on
Windows. All I see is the list the lets you change the address book directory
and the very top of the tabs.
My mistake.  I changed the editcarddialog.xul and clicked on the new card button
so of course I couldn't see the changes.  This looks good to me.  I say we
should just check this in(new card dialog as well) and unstop the blocker and
figure this out afterwards.  But, we should figure this out soon.
Status: NEW → ASSIGNED
Severity: blocker → major
we've met and figured it all out.

not a blocker, although the address book will have problems in the 7-26-99
build.

hangas is fixing all the xul to use overlays instead of iframes.  this will be
checked in after the tree opens.

moving from blocker to critical
Whiteboard: BLOCKER CONFIRMED
Well, Esther cannot test the address book until this is fixed so it's a blocker
for the address book, but not for general mail testing.  If the fix goes in for
the 27th builds, then this is acceptable.  Thanks.
Note:With todays builds the new card, edit card and Select addresses dialogs
don't even come up (see bug 10601), so this can not be rechecked until that bug
is fixed.
Using builds 19990730m9 (necko) all platforms, this is fixed.  Note: this is not
fixed in the last non-necko builds.  Should it be fixed in both?  If not I will
verify after resolution is marked fixed. If so I will leave opened.
Depends on: 11388
Target Milestone: M9 → M10
Whiteboard: [PR1]
I've continued to see some edit card sizing problems in August builds. This may
be due to fine tuning, like font sizes and wrapping, but I would not close this
bug yet.
This bug is still depending on 11388 for intrinsic sizing of dialogs containing

tab widgets.  We should leave this bug open until we are able to remove the fixed

size from the window and allow it to size to the content.
Moving to M11 because dependencies have not arrived.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Fixed.  The code to allow for dialogs to size to their content has been checked
in.  I am now using this and it is working.  New Card and Edit Card dialogs both
fixed.
Status: RESOLVED → VERIFIED
Using 19990922 builds on Win98, mac and linux this is fixed per original
scenario.  Verified
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.