Allison Naaktgeboren :ally Reporter
	Description • 11 years ago

e10s is not on the v1 mvp list, but I did find out today that it's being built incrementally, it's already on m-c, and it depends on omtc, which we now have (bug 866852). They may be interested in us as one of the few platforms that has omtc 

pref to turn on e10s: browser.tabs.remote -> true

What I found:
- about:start is great! Fastest I've seen it. The double buffer clipping issue is still present, but it's processed so fast that it turns into a flicker.
- context menus on about:start are dandy
- flyouts are fine
- about:config, about:sync not accessible
- loading a webpage/new tab results in a big blank white screen, no chrome accessible.
-- error console contains several uncaught exceptions for trying to load a single page.

[14:41:55.920] contentDocument is not available @ chrome://global/content/bindings/browser.xml:287
[14:41:55.983] uncaught exception: accessibleType: Supports Remote?
[14:41:56.365] contentDocument is not available @ chrome://global/content/bindings/browser.xml:287
[14:41:56.455] uncaught exception: accessibleType: Supports Remote?
[14:41:56.850] contentDocument is not available @ chrome://global/content/bindings/browser.xml:287
[14:41:56.859] uncaught exception: accessibleType: Supports Remote?
[14:41:57.500] contentDocument is not available @ chrome://global/content/bindings/browser.xml:287
[14:42:01.554] TypeError: content is null @ chrome://browser/content/browser-ui.js:372
[14:42:03.364] uncaught exception: accessibleType: Supports Remote?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 1 • 11 years ago

Sounds like we have a problem with D3D11 and e10s.

	Jim Mathies [:jimm]
	Comment 2 • 11 years ago

I flipped omtc off, which I don't think works with remote content processes and was able to render content. I'm also pretty sure the gfx backend we end up with in the content process is non-accelerated.

Misc issues:

1) content menu doesn't work. we still forward that over from content to chrome but something must have broken along the way.
2) touch panning isn't working. this is surprising, I would expect dom to deliver touch events properly to content, but something is clearly broken.
3) mouse cursors don't work. I seem to remember fennec having a similar issue, we probably have to forward cursor changes over.

	Tim Abraldes [:TimAbraldes] [:tabraldes]
	Comment 3 • 11 years ago

It might be obvious, but things aren't working as well with e10s enabled as they were when comment 2 and comment 0 were written.

In particular, if you enable e10s and launch MetroFx:
  - the browser chrome shows but the content (start page, or otherwise) never appears
  - the error console is full of messages like the following

Error: this.webNavigation is undefined
Source File: chrome://global/content/bindings/browser.xml  Line: 695

Error: browser is null
Source File: chrome://browser/content/browser-ui.js  Line: 362

Error: aTab is null
Source File: chrome://browser/content/WebProgress.js  Line: 192

Error: aBrowser is null
Source File: chrome://browser/content/browser-ui.js  Line: 872

Error: getBrowser(...) is null
Source File: chrome://browser/content/browser-ui.js  Line: 120

Error: TypeError: browser is null
Source File: chrome://browser/content/browser.js  Line: 653

Error: TypeError: Browser.selectedBrowser is null
Source File: chrome://browser/content/browser-ui.js  Line: 347


Apologies for any typos above: I had to manually type each error message because "copy to clipboard" is broken in metroFx when e10s is enabled (though that might get fixed when the desktop issue is resolved - bug 936089)

	Tim Abraldes [:TimAbraldes] [:tabraldes]
	Comment 4 • 11 years ago

Updating this bug to match the look of the other e10s tracking bugs. We can split this into front-end and back-end tasks later (like bug 879538 and bug 653064 for desktop Fx) or just file bugs that block this tracker.

	Tim Abraldes [:TimAbraldes] [:tabraldes]
	Comment 5 • 11 years ago

Apparently I don't need to manually add the alias to the title

	Tim Abraldes [:TimAbraldes] [:tabraldes]
	Comment 6 • 11 years ago

Not sure how that dependency got lost, re-adding

	Jim Mathies [:jimm]
	Comment 7 • 10 years ago

moving [story] bugs over to tracking product.

	Chris Peterson [:cpeterson]
	Comment 8 • 10 years ago

Metro e10s does not need to block desktop e10s.

	Kevin Brosnan [Ex-Mozilla]
	Comment 9 • 10 years ago

Conflicts with comment 8

	Chris Peterson [:cpeterson]
	Comment 10 • 10 years ago

Thanks, Kevin. Good catch!

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".

	Sylvestre Ledru [:Sylvestre]
	Comment 11 • 6 years ago

We never shipped the metro support, closing!