bug tracking feature in Summary.

Setting Target M14

accepting.

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

Sol, move back to M16 if we can't live without this in beta2.

[FEATURE] bugs past M16 are OUT for this release. Marking M20. If you disagree with this action, please help me explain it to the PDT.

Moving feature bugs to target milestone "Future" for next release consideration.

Jag, wanna take this?

I can take a stab at this.

This depends on bug 57984 and rewriting the menu to be an overlay.

Yay, I have a prototype working now. The menu, accel +/-, it all works, with maximal code sharing between navigator and mail/news (though that should really be turned around. Once I had my ZoomManager JS object and support code written and all neatly in an overlay, adding it to mail/news was only a few lines.) Next up is adding it to Composer and see if that goes just as well.

I'm putting this here to get some peer review on what I'm doing there. I want to replace the <box id="stringbundleset"/> with a <stringbundleset id="stringbundleset"/>, but at this point adding this overlay to mail/news requires as less as adding that <box>, a <menuitem>, and a function getMarkupDocumentViewer() (and the overlay, of course).

Seth or Bhuvan, could you give feedback on this first patch?

I've created a new bug (bug 64449) to track moving this code into its own overlay, marking this depend on it.

Bug 64449 is fixed, working on this part now.

Any idea when this will show up in the next nightly?

Well, as soon as I get r=, sr=, and an open tree :-) Anyone on the cc list wanna r= / sr=? :-)

r=timeless [w/ whitespace variance]

jag, can you explain the change from <iframe ...> to <browser ...> in the patch?

The <browser/> element is a rich iframe capable of offering the same drag & drop, HTML TITLE tooltip etc capabilities of the Navigator content area. The browser XBL widget is currently in construction but when it is complete all this functionality will be had for free simply by replacing an iframe with a browser. Clients are then able to customize the widget by adding their own context menu (which overrides the default), etc.

update: jag is double checking something for me (about the iframe -> browser change).

Change from iframe to browser seems safe (e.g. no one doing getElementsByTagName("iframe") or something like that). Attaching new patch which caches the messagepane element.

sr=sspitzer (note to jag, that patch contains a fix for another bug)

r=timeless

Checked in, marking fixed.

Jag, this menu item works fine on Windows 2000 build 2001020504 and Linux build 2001020506, but it's not even present on my Mac build 2001020513. Right after View | Headers, there are two seperators. Is something just missing in an overlay file?

Nope... Mac doesn't do this menu yet, and in the browser I chucked this in an existing section and could just hide the menu item. In Mail/News it looks like I'll need to add some logic to hide the separator I had to add. Patch coming up.

I can't pull on Mac, but I'll get this verified tomorrow. Thanks Jag.

r=blake

sr=sspitzer on the patch from jag on 2001-02-05 16:28

Fix checked in, marking fixed once more.

VERIFIED, build 2001021408 doesn't have this menu item present (nor the extra seperator.)