Get rid of nsIBrowserElementAPI.{set,get}Visible

RESOLVED FIXED in Firefox 55

Status

()

Core
IPC
RESOLVED FIXED
3 months ago
17 days ago

People

(Reporter: baku, Assigned: baku)

Tracking

unspecified
mozilla55
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox55 fixed)

Details

Attachments

(1 attachment)

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.
Created attachment 8872644 [details] [diff] [review]
visible.patch
Attachment #8872644 - Flags: review?(kchen)
Note that there is a TODO in ProcessPriorityManager. Currently that code is not used. I'm changing it in separate patches for bug 1366356
Blocks: 1366356
Attachment #8872644 - Flags: review?(kchen) → review+

Comment 3

3 months ago
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/78a9d7baaf8b
Get rid of nsIBrowserElementAPI.{set,get}Visible, r=kanru

Comment 4

3 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/78a9d7baaf8b
Status: NEW → RESOLVED
Last Resolved: 3 months ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Depends on: 1377656
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?
Flags: needinfo?(wmccloskey)
Flags: needinfo?(overholt)
I don't know, sorry. I'll be sure to ask baku to reply here or email you when he's back.
Flags: needinfo?(overholt)
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.
Flags: needinfo?(wmccloskey)
> 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>.
Flags: needinfo?(dtownsend)
(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
Flags: needinfo?(dtownsend)
You need to log in before you can comment on or make changes to this bug.