Bugzilla

To be clear, much of this discussion is about the possibility of an interim solution until bug 1411425 is fixed.

Would it be feasible to have Fission use a new process when under some limit (say 100 processes), or is the code starting to make assumptions that same process means same site?  I'm wondering whether 100 would be sufficient for the vast majority of users at least.

As a means for delaying reaching the limit, lazy GdkDisplay creation may be possible for when native widgets are drawn or sized, which is at least usually on-demand.  We'd still need to send at least some of the LookAndFeel info from the parent (bug 1470983 and/or bug 1503054) because some of this is not on-demand.  I don't have a good feel for how many cross-site iframes would use native widgets, but I guess that would be a smaller number.  Lazy GdkDisplay creation would help only if processes are being started and stopped often.  If processes are pooled for re-use, then they'll all end up having a connection.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)
> Does something like extracting all the geometry+style data we need from the parent process and forward it, then use Gecko instead of gtk to paint with that style information, sound doable?
> 
> So, like, make a Gecko re-implementation of `gtk_render_background` / `gtk_render_frame`, etc?

I expect this is doable, but a large chunk of work.  There would be a large number different combinations of widgets and states and properties to serialize, and there is also some likelihood that different GTK versions will have different implementations of the render functions.  Any interim solution would kind of be wasted work, given the plan is to remove it, so I'd prefer a solution with less work.

To be clear, much of this discussion is about the possibility of an interim solution until bug 1411425 is fixed.

Would it be feasible to have Fission use a new process only when under some limit (say 100 processes), or is the code starting to make assumptions that same process means same site?  I'm wondering whether 100 would be sufficient for the vast majority of users at least.

As a means for delaying reaching the limit, lazy GdkDisplay creation may be possible for when native widgets are drawn or sized, which is at least usually on-demand.  We'd still need to send at least some of the LookAndFeel info from the parent (bug 1470983 and/or bug 1503054) because some of this is not on-demand.  I don't have a good feel for how many cross-site iframes would use native widgets, but I guess that would be a smaller number.  Lazy GdkDisplay creation would help only if processes are being started and stopped often.  If processes are pooled for re-use, then they'll all end up having a connection.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)
> Does something like extracting all the geometry+style data we need from the parent process and forward it, then use Gecko instead of gtk to paint with that style information, sound doable?
> 
> So, like, make a Gecko re-implementation of `gtk_render_background` / `gtk_render_frame`, etc?

I expect this is doable, but a large chunk of work.  There would be a large number different combinations of widgets and states and properties to serialize, and there is also some likelihood that different GTK versions will have different implementations of the render functions.  Any interim solution would kind of be wasted work, given the plan is to remove it, so I'd prefer a solution with less work.