1368712 - Get rid of nsIBrowserElementAPI.{set,get}Visible

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Andrea Marchesini [:baku]]

These 2 methods are only used for b2g. I'm planning to remove them because I need a clean setup for the Priority Process Manager code.

Comment 1

[Andrea Marchesini [:baku]]

Attachment: visible.patch

Comment 2

[Andrea Marchesini [:baku]]

Note that there is a TODO in ProcessPriorityManager. Currently that code is not used. I'm changing it in separate patches for bug 1366356

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/78a9d7baaf8b
Get rid of nsIBrowserElementAPI.{set,get}Visible, r=kanru

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/78a9d7baaf8b

Comment 5

[Ben Francis [:benfrancis]]

Needinfo Andrew & Bill as Andrea is out and not accepting needinfos.

Hi, I was using setVisible and setActive in my browser (https://github.com/webianproject/shell) built on Mozilla's Quantum Browser Runtime (https://github.com/mozilla/qbrt) and this caused a regression for me.

What are the implications of this removal, do all mozbrowser iframes now have the same priority regardless of whether they are visible on the screen? This is going to be a real performance problem for anyone writing tabbed browsers in HTML as per the deXUL effort for Firefox.

I've been hoping that <iframe mozbrowser> would be replaced by <webview> for about five years now (https://bugzilla.mozilla.org/show_bug.cgi?id=webview) but presumably the Browser API or equivalent will still be needed for HTML chrome in Firefox in the future?

Are there any plans to replace this removed code with something else to either manually or automatically prioritise processes based on HTML iframe/webview visibility? Or should I switch from using HTML to XUL?

Comment 6

[Andrew Overholt [:overholt]]

I don't know, sorry. I'll be sure to ask baku to reply here or email you when he's back.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm not the right person to ask about out de-XUL-ification plans. If you want to know more about that, I think you can needinfo Mossop. Regardless of what we do, I don't think we should keep around code that's not being used right now.

Comment 8

[Ben Francis [:benfrancis]]

> I don't think we should keep around code that's not being used right now.

By "not being used" I guess you mean not being used by Firefox. Yet.

I know of at least three software projects which are still using this code. I realise that Gecko is now viewed as just the back end of Firefox rather than a platform for others to use and the Firefox team is quite happy to force any third party users of Gecko to move to WebKit/Blink, but my point is that the Firefox team is probably going to need this feature (or an equivalent) for Firefox in the future too.

Mossop, if Firefox migrates from XUL-based to HTML-based chrome then we'll need some way to prioritise open tabs. The XUL browser currently seems to set docShell.isActive directly to achieve this, but I'm not sure it's possible to get a reference to the docShell of a mozbrowser iframe from JavaScript in an HTML context?

Ideally the back end would be able to handle the prioritisation of processes automatically based on visibility, but so far this hasn't been possible so the application has needed some kind of API method to give hints to the back end.

Let me know if I can help design a new chrome-only <webview> element to replace <iframe mozbrowser> that can be supported long term and be used by Firefox in the future. I started on this in 2014 (http://benfrancis.github.io/webview/) and I'm currently looking at writing a polyfill on top of <iframe mozbrowser> and Electron's <webview>.

Comment 9

[Dave Townsend [:mossop]]

(In reply to Ben Francis [:benfrancis] from comment #8)
> Mossop, if Firefox migrates from XUL-based to HTML-based chrome then we'll
> need some way to prioritise open tabs. The XUL browser currently seems to
> set docShell.isActive directly to achieve this, but I'm not sure it's
> possible to get a reference to the docShell of a mozbrowser iframe from
> JavaScript in an HTML context?

Seems like it should be doable but that's a problem we can solve if we ever get there.

> Let me know if I can help design a new chrome-only <webview> element to
> replace <iframe mozbrowser> that can be supported long term and be used by
> Firefox in the future. I started on this in 2014
> (http://benfrancis.github.io/webview/) and I'm currently looking at writing
> a polyfill on top of <iframe mozbrowser> and Electron's <webview>.

We'll keep it in mind, thanks