62808 - Form manager dialog does not resize properly

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect, P3)

Description

[Stephen P. Morse]

From the menu select tasks->privacy->form-manager->view-captured-data
Note that the fields are not as wide as they could be
Note also that if the window is resized, the size of the fields does not 
increase

Comment 1

[Stephen P. Morse]

Attaching patch to fix the problem.  The files involved are:

   WalletName.xul
   WalletAddress.xul
   WalletPhone.xul
   WalletCredit.xul
   WalletEmploy.xul
   WalletMisc.xul
   WalletConcatenated.xul

Note that there are two sets of diffs for WalletCredit.xul and WalletMisc.xul.  
One set is with the conventional -u option and the other with the -u -w option.  
The reason is that these files had a formatting fixup which made it appear as 
though a lot of lines changes whereas the only change was indentation.  So the 
-w option showed which the true changes were.

Comment 2

[Stephen P. Morse]

Attachment: Patch to fix resizing problem

Comment 3

[Blake Ross]

Are () and ___ localizable (specifically, the latter)?  Also, I'm not sure, but 
I don't think percentage has any effect for |flex|es.

Comment 4

[Blake Ross]

er..."specifically the *former*", that is

Comment 5

[Stephen P. Morse]

This dialog will have a more serious problem with localization because things 
like addresses are laid out in a US-centric manner (zip code in two fields, 
addresses on three lines, etc.).  That was the reason I was reluctant to do a 
dialog like this initially but instead had the old wallet editor which simply 
listed all schema and their values in a vanilla manner, one after the other.  
Although such a display was schema-neutral and i18n-neutral, it was not that 
easy for the user.  That's why I decided to bite the bullet and redo the dialog 
as I did.

My thoughts are that l10n teams will have to redo the xul files as well as the 
dtd files in this case.  If that is what is agreed upon, the the xul files will 
have to be moved to the locale directories.  But that issue is outside the scope 
of this bug report.

Comment 6

[Stephen P. Morse]

Percentag does have an effect for flexes.  This was borne out by my experience 
in the use of such in several places in these xul files.  But I did have to set 
the width attribute to 0 in order for that to work (don't ask me why that's so, 
I simply found other examples in the code base and I copied them).

Comment 7

[Blake Ross]

What's the reason for the various <column/>'s?  Also, is specifying value="" 
really necessary?

Comment 8

[Stephen P. Morse]

I may have misunderstood your question about percentages.  I was replying that 
indeed we can have flex use a different percentage for different items.  But 
your point may have been the the percent sign itself is unnecessary and that 
simply by having a number with no qualifier after it will default to percentage.  
I don't know if that is true or not.  But if so, isn't it ambiguous when you 
have flex="1" as to whether that's 100% or 1%?

Comment 9

[Stephen P. Morse]

The <column/>s are inside <grid>s.  They are paired with <column flex="1"/> 
which indicates that the first one takes as much room as it needs and the other 
expands to take all the remaining space.

The value="" on the menuitems might not be absolutely necessary, but they dont' 
hurt and they make for clarity in specifying that the menulist always has a 
menuitem that is blank.

Comment 10

[Blake Ross]

Alright, looks okay.  I have some issues with the <menulist/>s used here, but 
I'll split those off later. r=blake

Comment 11

[Blake Ross]

cc'ing alec to sr

Comment 12

[Alec Flett]

sr=alecf - I'm with blake, I think we eventually need to clean up this XUL

Comment 13

[Stephen P. Morse]

Fix checked in.

Comment 14

[Terri Preston]

Verified fixed w2k build 2001082303