Noticed this while using the 5/11 build. Is the problem in table Layout, or somewhere else?

Vidur, can you take a look at this and figure out who should get it. I'm not sure if the pop ups work using layers.

Definitely layers, but I heard recently that slamm started delivering differnt content to Gecko.

Assigning all layers bugs to ekrock.

If Tinderbox has a dependency upon the Nav4 Layer DOM API/document.layers, Tinderbox must be updated to use the W3C DOM in Nav5 as document.layers won't be supported in Nav5. Reassigning to default owner of WebTools.

I changed tinderbox so it does not use layers if it detects 5.0. You now get the same behave as pre 4.x browsers. I can add nifty CSS2 and HTML4.0 support to tinderbox but I am not considering this a high priority. Correct me if I am wrong. Moving out to M10.

Changed to RFE for consideration at M14, and summary from "Tinderbox doesn't show comment pop ups over stars".

Since Tinderbox has been modified to eliminate the dependency on layers, this is no longer a layer-related bug (it's now an enhancement request for Tinderbox), so I'm eliminating the dependency of 8023 (layer bug tracker meta bug) on this report.

Steve, is there any way you'll actually have time to get this done by M14? If not, move it up to M15.

This would be a good feature to have! Then I can stop loading navigator to view tinderbox.

I wrote some revisions to the tinderbox HTML/JS to make Tinderbox work with Mozilla basically the way it does in NN4.x. They are diffs against a random copy of http://tinderbox.mozilla.org/seamonkey/, but I don't imagine it would be too hard to apply the changes to wherever the source is generated. I put the diffs(tind.diffs), the original page I based the modifications on(tind.orig.html), and the modified page (tind.html) at http://www.people.fas.harvard.edu/~dbaron/tmp/tinderbox/ for anyone who wants to test them or apply the patch. A few things in the code are a bit ugly: * I have the popups close when you click outside of the popup or open another (rather than on mouseout), because mouseouts don't work too well on certain things. * The popups have fixed sizes. Doing a better job would require either one of: + some IE-compatibility DOM additions, or something similar + changes to absolute positioning that Troy is likely to make soon. I should file bugs... I tested the revised page in Nav4 and in Mozilla (yesterday's build). Note that many of the changes to the JS code are indentation changes where there are now separate codepaths for NN4 and Moz.

Move to M16 for now ...

Since Mozilla has been at dogfoot for some time now, should it be considered an enhancement to expect the same functionality out of Tinderbox when using Mozilla? I wish I really fealt confortable with Pearl. I would try to go through the Tinderbox script in the webtools tree and see how difficult it would be to implement David's patch.

All this requires is pasting in the modified code around: http://lxr.mozilla.org/mozilla/source/webtools/tinderbox/showbuilds.cgi#528

... and updating tinderbox to use the revised code, once tested to the satisfaction of whoever's doing it.

I have checked in dbaron's patch with some minor changes to the browser detection code.

Fixed and running.

I hate to say this, but I just tested this again (I hadn't looked at it for a while) and the L, C, and * aren't working for me in today's build. I suspect this could be related to the absolute positioning changes I mentioned above, which troy made a few days ago, although I don't see why they should break it. I don't have too much time to investigate this right now...

cc:ing troy for insight. It definitely is an absolute positioning problem. The L, C, and * popups are being pushed down to way below the bottom of the page (so the page gets longer) while the name popup (which is an iframe rather than a div) is not.

Except I didn't actually cc: troy. troy - could you see my previous comment.

'C' doesn't have a popup -- it appears to be working fine. The "Guilty" names work too. The bad thing about 'L' and '*' not working is that the popup steals the click event, so you can't get to the logs (unless you scroll down forever to find the popup). This is probably worse than no popups at all so I'm thinking of backing this out. Anyone have a quick fix?

You can right click "Open in new window" to bring up the links. The "who" popup is amusing: the checkins page appears *inside* the popup

Here's a really quick fix: .note#popup, .log#popup { position: fixed; top: 50%; left: 50%; } It just puts the problematic popups right in the middle of the screen. It also requires removing one other line (the only occurrence of that line) that shouldn't be there anyway. Full diff (not directly applicable to a file, but...) at: http://www.people.fas.harvard.edu/~dbaron/tmp/tinderbox/hack.diff

This should be reopened.

Even better (really centered, rather than corner-centered) would be: .note#popup, .log#popup { position: fixed; top: 0; bottom: 0; left: 0; right: 0; margin: auto; }

The problem with the who popup should be fixed by changing http://lxr.mozilla.org/mozilla/source/webtools/registry/who.cgi (I assume that's what generates the popup) to change the line print "Content-type: text/html\n\n<HTML>\n"; to print "Content-type: text/html\n\n<HTML><base target='_top'>\n";

I guess I missed the beginning of this. Sounds like absoluite positioning is used to position the pp-up which makes sense. What are the style rules used to position it?

troy - see http://www.people.fas.harvard.edu/~dbaron/tmp/tinderbox/tind.html to see the problem, since it won't change. The style declarations (for .log#popup) are: position: absolute; height: 10em; width: 15em; margin: -5em 0 0 -5em; border: 2px solid black; background: white; color: black; padding: 0.5em; (This should I think position relative to the normal flow parent, but it's ending up at the bottom of the screen. The same problem exists with the height and width removed, which now works -- see http://www.people.fas.harvard.edu/~dbaron/tmp/tinderbox/tind2.html )

Okay, I just fixed a problem in the nsHTMLReflowState code that was causing the hypothetical box calculation to be whacky, and now things look much better I think it's being positioned correctly, but you may want to adjust your margins slightly if you're not happy with the location Note that because the absolutely positioned element is a DIV it would have been block-level and so I calculate the hypothetical box based on that fact

Thanks Troy -- this is working again in today's build. I'll leave it to someone else to make tinderbox pretty.

Actually, thanks to all of you on this. As far as making this prettyier, perhaps that can be rolled into fixing bug 18155.

The problem with the "who" popup should still exist. Could someone make the change in my comment dated 19:34 yesterday? (Does this change just need to be checked in, or does it need to be propogated to a server too...?) In a few weeks (perhaps after M16), we can change tinderbox to depend on the absolute positioning changes troy made a few days ago. This will make the popups size to their content (which is the biggest problem right now, although that they can be off-screen is also a problem). Or do you think it's a fair assumption that everybody interested in tinderbox should be using a current build?

I checked-in the who.cgi changes this morning, trying to find Dawn to refresh the copy used on the site.

Is there any way to make this work on IE as well? To fix 36164 I just blocked all IE users from DHTML content (figuring that there won't be many). But if it's not possible then web authors are still stuck in the hell of creating alternate content for mozilla and IE -- and given IE's marketshare we will lose in that situation.

In theory the code that I wrote for Mozilla should work (or come very close to it) on IE5 (but I don't think on IE4). I'm not in the mood right now to reboot into Windows and check, but maybe later...

It didn't work on IE 4.01 -- it didn't think there was a nodeType property of the event target. I'll try it on IE 5 if I can find one, and if it works I can change my check for "MSIE" to "MSIE 4".

Verified fixed in the July 14th builds.

Unsetting target milestone so we can delete the old (inappropriate) Mozilla target milestones from Webtools.