There are no textboxes shown in any of the Form Manager's expected places. To Reproduce: 1. Download and install this Mac build of Netscape 6 ftp://sweetlou/products/client/6.x/macos/8.x/ppc/2001-06-19-08-trunk 2. Open Netscape 6 3. Click on Tasks | Privacy and Security | Form Manager | View Stored Form Data 4. Notice on the right hand side of the new popup there are no textboxes where we might expect them to be.

ftang checked in a fix for this yesterday.

reopen. I can see the mac problem on 06/19 build. but the same behavior as moz0.9.1 (or netscape 6.1 beta1) build. Therefore, this bug have no relationship with 85300. 85300 does not regress this neither improve it. reopen since it is not a dup of 85300 and the problem still exist.

OK, I'm not sure if it would be better to file a new bug instead of widening the scope of this bug to linux, too, but as bug 85300 is closed now and this bug's description matches the linux problem, I put it here. I repeat the description for the linux case from #85300 here: The formmanager still (20001061914, linux, modernskin) DOES NOT WORK. The first panel (Name) comes up allright, all other panels remain blank --- but most panels will eventually appear when you resize the dialog. But even when they appear, The layout is broken when dropdown lists are used (see attached screenshot of the creditcard panel es an example). Basically the situation is not better than it was some weeks ago. Can you, Peter, confirm if the behaviour on Mac is the same as on linux (that means, can you force the text inputfields to appear by resizing the dialog)??

per outside email with morse, reopening, this is not fixed on mac build 2001062005, sounds like the linux problem is the same, I will look into that now

um, re-opening

Seeing completely blank form manager windows for everything except the very first selected page (the one selected by default when Form Manager window appears). Other pages are blank. Build 2001062411... Linux.

Oh, and resizing the Form Manager window makes the page redraw and all the controls appear. Though Credit Cards pane surelooks as ugly as the screenshot above.

Changing OS from MAC to all because this occurs on unix as well. Unfortunately there is no way to specificy MAC+UNIX but not windows. This is not a problem with form manager, but rather with the underlying infrastructure. Reassigning. This is a must-fix for rtm in my opinion.

ick. perhaps this has something to do with the paint suppression.

Nah, if it were paint suppression, nothing would paint at all.

--> bryner

bryner is out for 2 weeks. jag said he'd look at this.

###!!! ASSERTION: A Box's child is constantly growing!!!!!: 'passes < 10', file /u/jaggernaut/nscp-src/mozilla/layout/xul/base/src/nsSprocketLayout.cpp, line 504 ###!!! Break: at file /u/jaggernaut/nscp-src/mozilla/layout/xul/base/src/nsSprocketLayout.cpp, line 504 That's probably what's causing the weird credit card panel look. Anyway, that seems like a different bug.

Peter, this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the first RTM candidate. It would be good, if this could be resolved ASAP.

Discoveries so far: - Turn on "Disable XUL Cache" in Edit -> Prefs -> Debug -> Networking, and the panels will show immediately on Linux and Mac. This points at weird cache interaction. - On linux, laying out <grid>s is awfully slow for some reason. The way the (editable) <menulist>s are used here makes it even worse, because each list is initialized (with the item to be selected), and each initialisation causes a reflow, thus a re-layout of <grid>. darin, dougt, any ideas about the first issue? evaughan, any ideas about the second issue?

Bug 89133 for the linux grid layout bug.

So since this works fine when I disable the cache, I'll for now blame the cache and assign it to that component and its owners.

Jag - xul cache and "networking: cache" are two different things. I am not sure where xul-cache bugs should go... Chris?

-> XPToolkit/XUL

What dougt said. The XUL cache refers to the XUL prototype document stuff, see content/xul/document/src, especially nsXULPrototypeCache.cpp and nsXULDocument.cpp. Usually this stuff ends up being a timing issue with asynchronous XBL loading, which is content/xbl/src. So, it's almost certainly toolkit bug, probably with some control getting wedged if it gets initialized in the wrong order.

... and around the horn, and back to jag (although perhaps evaughan might have a look at this box layout problem).

Wheeee! At least now I have a better idea of where to look :-)

jrgm just tested a couple of linux builds back to 2001-01-17-06, and all had the Form Manager show up blank. So this hasn't worked for nearly 6 months (that we can verify). One quick hack I'm persuing for the moment is to resize the panel vertically by 1 and then -1 to force a redraw, on any non-Win platform. Not the right way to fix it, but it would hopefully remove this bug from the PDT+ list.

Unfortunately the formmanager isn't really fixed by making it display (see the screenshot, and other panels of it). One could argue that it's better for the mental sanity of the world that it doesn't display at all until the layout works, too.

Well, the Mac can benefit from this patch until we find a better solution. As to linux, that's why I filed bug 89133.

I just tried this on my trunk build from last night on MacOS 9.x and it seemed to display all the controls just fine... might want to double check if this hasn't been fixed by other things.

on saari's mac trunk build, the panels don't show until you resize the window, but when you do that, they show just fine. Is linux the same way? If so, this might be alright for ship.

Yeah, that (resize forces panel contents to display) was known and is the basis for my "fix". It seems that even with that knowledge this got PDT+ed. But if you can convince PDT that a resize (on Mac and Linux, Windows is fine) is a good enough work-around, I'd say go for it.

sr=blake

r=pchen

Please check this in to the branch (and trunk as applicable) as soon as you're able to. It appears this bug has the r and sr associated for the patch. Thanks.

Checked into the trunk.

Backed out from the trunk, checked into the branch. This shouldn't have gone on the trunk in the first place, the work-around is too ugly for that.

Removing PDT+ now that this work-around is checked in on the branch. Retargetting 1.0 and assigning to hyatt.

Unsetting the target, hyatt can make a better guess himself.

yes! branch is working now!! seen on linux 2001-07-09-04-0.9.2 & mac 2001-07-09-03-0.9.2 will the fix go into trunk soon?

Nope. This isn't a fix, but an ugly work-around which "fixes" a symptom. It will not go into the trunk as is, instead we'll try to find out what the cause of this bug is and fix that.

bryner and I figured out a real fix for this.

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

It should be mentioned that the problem no longer manifests itself with form manager because a work-around was implemented allowing form-manager to sidestep this problem. See bug 89514. So you might want to update the summary line to describe the underlying problem rather than the form-manager symptom.

That work-around wasn't checked in on the trunk, so it's still there, I think.

No, it's the other way around. It was checked in on the trunk only. pdt rejected it on the branch, much to my surprise, which means that the problem with form manager will occur in our 6.1 shipping product.

You are correct that your patch which changed the <html> to <text> was only checked in on the trunk, but that didn't fix this blank form manager case, but the form manager "hanging" case. The form manager blank case was "fixed" by resizing it vertically by 1, then -1, aka "The Wobble", which only was checked in on the branch, and not on the trunk. Since this bug and latest patch are about fixing the "comes up blank" case, I thought that's what you were talking about (I didn't look at the bug you mentioned, which I should have I guess).

Sorry, I got confused. The image that is posted in this report didn't show a blank form-manager but rather showed one that had the fields all contorted. That problem was fixed by the so-called hanging bug 89514. It wasn't really a hang but appeared to be so because it took so long to come up, and when it finally came up it looked like the attached image. So I take it that the blank problem is yet something completely separate.

waterson, you asked: Hey Chris K., Marc mentioned that you might know if there is code that thinks it needs to get a reflow before the initial reflow arrives? Or that relies on getting a reflow (a ``timeout reflow''?) after it's been initially reflowed? AFAIK, nothing in the block code depends on this. Do tables? Comments to the bug please... ---- Tables don't need any other kind of reflow prior to the initial reflow. However, they do use a special timeout reflow to ensure that they will get a reflow before the pres shell runs out of reflow commands or gets timed out. It is a fairly simple mechanism whereby the pres shell has an additional queue containing timeout reflow commands that it is to process. I don't think the patch will defeat this mechanism

I don't see any mention here of a checkin for the trunk, but as of Friday mornings builds this is finally fixed!!! *yippee skippee* I think this is an excellent feature of NS6 and am very pleased to see this working on Linux and Mac. It's been a long time coming, but I knew it was on it's way as 0.9.2 was fixed a month ago. Marking fixed as seen on commercial builds: linux 2001-08-03-06-trunk mac 2001-08-03-04-trunk

Whether or not the actual bug is fixed, there are underlying issues here that probably still need to be resolved, right? So this bug shouldn't have been closed without filing a new bug for them. Or is there already a separate bug?

The underlying issues haven't been fixed. I'll attach a test case that illustrates the problem

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

Sorry, let me be a bit more clear. The above patch _fixes_ the original bug that was reported (form manager doesn't show up); however, the original bug has been hacked around in the current code IIRC so that it no longer appears. The test case that I just attached illustrates the bug; applying the attachment 44344 [review] should fix it.

r=karnaze

sr=hyatt

Uh, ok. So it looks like I accidentally checked in the nsCSSFrameConstructor changes already. Just checked in the changes to nsPresShell; marking fixed.

verified