64325 - Form manager unusable, can't see field names or enter data in fields

Status: VERIFIED FIXED

(SeaMonkey :: Themes, defect, P2)

Description

[Terri Preston]

1. From the new form manager toolbar, click view saved data
2. Click on any of the choices below name (Notice you can't see half the field 
of the title of the field
3. Click back to name, now the same problem occurs with name

Expected Result: should be able to see and enter data in the fields

Actual Results: form manager is unusable

I have seen this on the mac build 2001010408-Mtrunk (Classic and Modern theme)
Checking on other platforms

Comment 1

[Stephen P. Morse]

Terri, isn't this a dup of either bug 62722 or bug 63616?  Marking it as a dup 
of the latter.

*** This bug has been marked as a duplicate of 63616 ***

Comment 2

[Terri Preston]

I don't think so, this is behavior that just began today. 63616 is simply that 
the fields are too small, this bug refers to the fact the fields become "hosed" 
and therefore this feature becomes completely unusable.

62722 refers to menus and skins, has nothing to do with this as it occurs in 
classic and modern

Also, I see weird behavior in Linux as well, if you save some data, such as 
name, password and address, when you go to view the data, again, name is fine 
but if you click anywhere below name, no fields are available and when you click 
back on name, it no longer appears.

So, I think this is a new bug but I'll leave it up to you

Comment 3

[Stephen P. Morse]

OK, if it just began today then it's not a dup.  Removing the dup indication.

Comment 4

[Stephen P. Morse]

Does any of this behavior happen on windows?

Comment 5

[Terri Preston]

No, Windows is fine, although your new toolbar does not show up on 98?  (Build 
2001010404)  If you go to view toolbars, it's listed and checked but does not 
show if checked or not (different bug, huh?)

Comment 6

[Terri Preston]

If I change profiles, the toolbar appears

Comment 7

[Stephen P. Morse]

This sounds like a new bug so file a new report on it.  Thanks.

Comment 8

[Fabian Guisset]

The toolbar pops up only when first launching Mozilla or when viewing a page 
which has a form in it, that's why you couldn't see it, tpreston, me thinks.

Comment 9

[Dave Cohrs]

This bug does not appear to be Mac System specific.  I see the same behavior on
Linux using 0.7.

Comment 10

[Vladimir Kondratiev]

This bug is in place for Linux build ID 2001012221.
I see fields for 1-st/last name,
but pages corresponded to other entries on the left side are just empty.
Forms are, however, filled correctly with previously captured data.

Comment 11

[Tracy Walker [:tracy]]

seening on commercial builds:

windows 2001-02-13-06-mtrunk
linux 2001-02-13-06-mtrunk
mac 2001-02-13-04-mtrunk

this bug got worse.  before when you went to the form manager and previewed the 
stored forma data there would be fields present. Complete fileds on windows and 
partial fields on mac and linux.  now when you get to preview window on all 
three platforms the preview pane is empty

Comment 12

[Stephen P. Morse]

Could you attach a screen shot that shows what you are referring to?

Comment 13

[kysmith0 (gone)]

Attachment: screen shot of empty form manager window

Comment 14

[Chris Waterson]

steve: I think this was my fault! I backed out my changes, but want to make sure 
that the problem goes away (and that I don't break it again in the future). How 
do I get to the form manager dialog? I don't seem to have the form manager 
toolbar in my build.

Comment 15

[Stephen P. Morse]

The toolbar was removed last week.

But you can get to the dialog that demonstrates the problem from the task menu 
as follows:

   tasks->privacy->form-manager->view-saved-data

Comment 16

[Chris Waterson]

Fixed when changes backed out for bug 39054.

Comment 17

[Stephen P. Morse]

No, I don't thing it's fixed.  The original problem was reported on January 4 
and had to do with the fields being clipped or something similar.  It got worse 
this morning in that the fields were gone completely and that was what twalker 
commented on.  Your checkin today brought the fields back but probably had no 
effect on the original complaint.

Comment 18

[Tracy Walker [:tracy]]

verified back to original bug state on commercial builds:

linux 2001-02-14-06-mtrunk
windows 2001-02-14-06-mtrunk (note: on windows this makes it back to functioning 
correctly...this bug is a linux and mac bug)

Comment 19

[Stephen P. Morse]

Still not convinced that this isn't a dup of bug 63616.  Assigning to andreww 
(since he already has that bug assigned to him) to determine if they are 
related.  Also cc'ing [e-mail] since he has the companion bug 62722.

For clarification, bug 62722 is about editable-menulists never having been 
implemented in any theme other than classic.  So it's a feature that was never 
completely implemented.  Whereas bug 63616 says that even in classic skin the 
implementation of editable-menulists has problems on platforms other than 
windows.

Comment 20

[Stephen P. Morse]

Really assigning to andreww this time (I thought I did that on 2-14 but 
apparently I didn't click on the right thing).

Comment 21

[andreww]

Looking at this today.  

Comment 22

[andreww]

not sure if this is skins related, still investigating, but I found a workaround
- if you resize the dialog (at least on mac ) the forms elements "return"...

Could this be a layout bug? Still looking.

Comment 23

[Daniel (Leaf) Nunes]

bugzilla seems to have lost my reduction in severity... there is a workaround... 
moving to critical

Comment 24

[andreww]

Thanks, I was about to do that. :)
I'm betting it's something to do with having that titlebox inside the panel. I
saw this in tabs, and perhaps it's showing up in titleboxes too now.

Comment 25

[andreww]

*** This bug has been marked as a duplicate of 68693 ***

Comment 26

[andreww]

argh. darn bugzilla. wrong bug... reopening

Comment 27

[andreww]

I think I've hit on the key to this bug, thanks to a comment from evaughan - and 
I'm going to test it out on my local copy.  I believe the source of the problem 
is that there are HTML widgets in the form xul files, which evaughan said  may 
cause layout problems.  I'm testing this right now...

Comment 28

[Stephen P. Morse]

When you say "form xul files", are you referring the the xul files in 
extensions/wallet/editor?  If so, these are the same html widgets that you find 
in the prefs files (xpfe/components/prefwindow/resources/content) and, in fact, 
the form-manager files were derived from those pref files.

Comment 29

[andreww]

I've tried everything I could think of to either work around this or try to get 
to the root of the problem. I see this on every skin I've tried (around 6 or so 
including sky-pilot) and the strange thing is that the contents of the iframe 
will in fact show up if you resize the window even just 1 pixel, which lends me 
to believe that somehow the iframe is not getting a repaint or refresh when it 
initially needs to , and that by my resizing the window, it then in fact 
completes the display.   Marking helpwanted. I believe this is beyond a themes - 
specific issue.

Comment 30

[Chris Waterson]

It sure reminds me of the `mail headers not visible after folder switch' bug.

Comment 31

[rubydoo123]

reassign to evaughan for debugging

Comment 32

[andreww]

Aha! I've continued to beat this horse till it coughed forth some clues.  I am
posting two examples of WalletName.xul. One which "works" and one which "doesnt".
The only difference is that the one that works has only one <row> tag in it's
grid.  The one that "doesnt" has multiple row  tags. Would this point to a grid
problem?

Comment 33

[andreww]

Attachment: A version of WalletName that "works" - you can see it without resizing

Comment 34

[andreww]

Attachment: A version of WalletName.xul that "doesnt" work - you have to resize the window in order to view it otherwise its blank

Comment 35

[Peter Trudelle]

->moz0.9.1/p2

Comment 36

[andreww]

*** Bug 74014 has been marked as a duplicate of this bug. ***

Comment 37

[andreww]

please look at bug 74014 (just marked dupe) - it has more test cases which might 
assist in fixing this bug.

Comment 38

[Stephen P. Morse]

Looks like I made the same discovery on 4-1 in bug 74014 that andreww made here 
on 2-22.  Namely that things work fine for a single row but not for more than 
one row.  See my detailed comment of 2001-04-01 11:18 in bug 74014.

The difference between the test case that I posted in 74014 and the one that 
andreww posted here is that mine is a self-contained set of four xul files 
independent of our chrome.  Andreww's was a modification of files in the chrome 
used by form manager.  Other than that, the test is identical.

Also I made the observation in bug 74014 that the problem goes away if you do 
either of two things:

1 - Reduce the number of rows to one (as already mentioned here)
2 - Remove the "editable" attribute from the menulist

Neither of these are acceptable work-arounds for the problem of course.  But I 
repeat them here in case they give any clues to the underlying cause of the 
problem.  In particular, the "editible" attribute.

Furthermore, this bug (as well as 74014) are marked as platform:all.  In my 
observations (as noted in bug 74014), this works fine on windows but not on 
linux (I did not test mac).

Comment 39

[andreww]

It's "all" because there is no way to say "mac and linux but not windows".  I see 
this problem on mac (both / all skins)

Comment 40

[Stephen P. Morse]

*** Bug 75755 has been marked as a duplicate of this bug. ***

Comment 41

[Peter Trudelle]

resolving as wfm using today's bits on Mac, Linux and Win98.

Comment 42

[Terri Preston]

I am still seeing this on Mac build 2001050104, in both classic and the new 
modern theme, on linux build 2001050108, if you click anything other than name, 
no text fields will show (No windows builds today)  So, form manager still 
unusable

Comment 43

[Peter Trudelle]

Okay, I can repro on Linux today, although all fields appear on resize. Due to 
our excess bugload, I think that workaround is going to have to be enough for 
our beta testers. ->0.9.2

Comment 44

[Terri Preston]

*** Bug 77883 has been marked as a duplicate of this bug. ***

Comment 45

[Viswanath Ramachandran]

Should this not be nsbeta1? adding the keyword. 

Comment 46

[Tracy Walker [:tracy]]

this is now present on windows commercial build 2001-06-08-06-trunk

and the viewer has become worse on all platforms; even the Name fields are 
unviewable now.  Still not a blocker because using prefill form will bring a 
viewer that does show all prefilled fields.

Comment 47

[Simon Fraser [no longer active]]

Note that bringing up the wallet viewer now gives a JS error:

JavaScript error: 
chrome://communicator/content/wallet/WalletViewer.js line 123: elementIDs has no
properties

Comment 48

[Simon Fraser [no longer active]]

*** Bug 85300 has been marked as a duplicate of this bug. ***

Comment 49

[Stephen P. Morse]

This is an old bug that was fixed.  The symptoms and the cause are different 
from what is now being observed.  Bug 85300 is the correct report for the new 
symptoms.  I'm going to undup these two reports and keep this one closed out as 
fixed.

Comment 50

[Terri Preston]

Okay, then I'm marking verified