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

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 ***

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

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

Does any of this behavior happen on windows?

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?)

If I change profiles, the toolbar appears

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

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.

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

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.

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

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

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.

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

Fixed when changes backed out for bug 39054.

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.

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)

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 hewitt@netscape.com 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.

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

Looking at this today.

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.

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

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.

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

argh. darn bugzilla. wrong bug... reopening

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...

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.

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.

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

reassign to evaughan for debugging

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?

->moz0.9.1/p2

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

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

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).

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)

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

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

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

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

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

Should this not be nsbeta1? adding the keyword.

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.

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

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

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.

Okay, then I'm marking verified