Bug 130078 Landed

I landed bug 130078 a few days ago. Bug 130078 is about removing platform specific widgets (or windows) from the content area of the browser. These widgets cause us a lot of problems and there really is no need for them. It was a significant limitation in our core architecture that is now fixed. Removing these widgets has many benefits: it will allow the hardware acceleration work that is going on to proceed more smoothly, it gets us a lot of incremental performance improvements in different areas, and allows us more flexibility in drawing the browser chrome with the browser content and other areas. For example, it lets extension and chrome authors layer arbitrary chrome elements over content IFRAMEs and they can even apply any CSS effect to content IFRAMEs.

We’ve actually been removing widgets from Gecko for over a decade now. Back in 1999 (I’m told) native widgets for most form controls were removed from Gecko. Last year Robert O’Callahan removed widgets from scrolled areas and IFRAMEs in content documents. Then recently Jim Mathies merged the two widgets we had at the top of every window (on the Windows platform) into one so that we could draw in the titlebar. And finally bug 130078 removed widgets from root content documents, so there is only one widget left (on Windows at least), and we need to keep that one unless we want it to be a text based browser.

I’ve been working on this for quite a while, but Robert O’Callahan has been laying the groundwork for this change for years now and has done a huge amount of the work needed for bug 130078. He may be a little jealous that I got to finally push the changesets that kill this bug after he has been wanting to kill it for such a long time now. I also couldn’t have done it without the help of Karl Tomlinson, Mats Palmgren, Jeff Muizelaar, Bas Schouten, Jim Mathies, Chris Jones, Oleg Romashin, Kyle Huey and others that I’m probably forgetting.

Advertisements

  1. tom

    what about flash (and other plugins) in OOPP world? do they still get the HWND or not?

  2. You forgot one other big benefit of this one.

    It should finally make web pages work properly in XUL panels.

  3. This really is fantastic news. Thanks for putting up with all the “is it done yet” nagging!

  4. James Napolitano

    Does this change help along roc’s Compositor (which is marked as a blocked bug)?

  5. Does this mean the pink comment on https://developer.mozilla.org/en/XUL/panel can be removed (with appropriate versioning info)?

  6. Mook

    This also means any binary extensions or external applications which tried to get at the window handle will break. In the smarter cases they have probably been going through the accessibility code (since there is no supported way to do so via XPCOM, see bug 269323).

    Overall, though, this is an exciting change to have 😀 Possible browsers-in-panels, non-rectangular main windows, and other fun things, yay!

  1. 1 The Burning Edge » Blog Archive » 2010-08-30 Trunk builds

    […] Fixed: 130078 – Integrate iframe into chrome view hierarchy (link view managers / trees between chrome and content). (tn's post) […]




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s



%d bloggers like this: