1519514 - Convert tab bindings

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, task, P5)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

The following bindings can be converted to custom elements by prepending/appending elements when CE connects.

They would need the basecontrol mixin to be landed in bug 1518932.

• tab
• tabbrowser-tab

Specifically for tabbrowser-tab we could move the complexity to its only user if applicable.

Watch out for performance issue with a lot of tabs though.

raw note:

tab
Has <content> + <children>, but it’s only prepending and appending. Used lightly (devtools and maybe one other place).
tabbrowser-tab
Coupled with tab. Could be used as a tab with [is].
Look into performance + sessionrestore with a lot of tabs

Comment 1

[alexander :surkov (:asurkov)]

Attachment: Bug 1519514 - convert tab binding to a Custom Element, r=bgrins

Comment 2

[alexander :surkov (:asurkov)]

Attachment: Bug 1519514 - hg copy tabbrowser.xml to tabbrowser-tabs.js to preserve history for tab binding conversion to a Custom Element, r=bgrins

Comment 3

[alexander :surkov (:asurkov)]

Attachment: Bug 1519514 - convert tabbrowser-tab binding to a Custom Element

Comment 4

[alexander :surkov (:asurkov)]

I've run into a tooltip over tab icon problem (D26602 patch). If I make tab's content explicit, then document.tooltipNode is tab's icon the mouse is over at, which is expected I think. If I put tab's content into shadow DOM, then document.tooltipNode is parent tabs element for unknown reason.

Emilio, do you have ideas on this issue?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Without having looked at it for too long, seems like ultimately the result of that operation comes from:

https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/layout/xul/nsMenuFrame.cpp#628

Is there any chance that popup is using the anchor attribute, and that either the popup or the target of the anchor are now in a Shadow tree?

Comment 6

[alexander :surkov (:asurkov)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Without having looked at it for too long, seems like ultimately the result of that operation comes from:

https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/layout/xul/nsMenuFrame.cpp#628

Is there any chance that popup is using the anchor attribute,

unlikely, I don't see setAttribute for @anchor in code, https://searchfox.org/mozilla-central/search?q=setAttribute%28%22anchor&path= or relevant anchor="" in markup, https://searchfox.org/mozilla-central/search?q=+anchor%3D&path=

and that either the popup or the target of the anchor are now in a Shadow tree?

popup is an explicit node living in browser.xul, aka tooltip#tabbrowser-tab-tooltip, https://searchfox.org/mozilla-central/source/browser/base/content/browser.xul#585

Comment 7

[alexander :surkov (:asurkov)]

It appears that when the test waves over <image.tab-icon-sound> icon located in tab's shadow DOM [1], then mouse move event target is <tabs id='tabbrowser-tabs'> element [2]. Does it look like eventing bug?

[1] https://searchfox.org/mozilla-central/source/browser/base/content/test/tabs/browser_audioTabIcon.js#61
[2] https://searchfox.org/mozilla-central/source/layout/xul/nsXULTooltipListener.cpp#265

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Looks like the XUL tooltip code should use GetComposedTarget / GetOriginalTarget instead of GetTarget. Sorry, should've thought of that. See bug 1489440 for a similar issue.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Looks like the XUL tooltip code should use GetComposedTarget / GetOriginalTarget instead of GetTarget. Sorry, should've thought of that. See bug 1489440 for a similar issue.

XUL tooltip tries GetComposedTarget (which is <scrollbox> in this case), and then if doesn't have GetContainingShadow (it doesn't), then it falls back to GetTarget(), which is <tabs>, see [1].

Honestly I'm not sure how the tooltip logic should be modified to make tooltips work. Also having <tabs> as an event target of mouse move over tab's shadow DOM icon is confusing, because <tab> is an explicit child of <tabs>. Either I don't understand what event target is or there's some eventing bug :)

[1] https://searchfox.org/mozilla-central/source/layout/xul/nsXULTooltipListener.cpp#178

Comment 10

[alexander :surkov (:asurkov)]

ni? from Emilio on comment #9

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Honestly I'm not sure how the tooltip logic should be modified to make tooltips work. Also having <tabs> as an event target of mouse move over tab's shadow DOM icon is confusing, because <tab> is an explicit child of <tabs>. Either I don't understand what event target is or there's some eventing bug :)

Event.target is retargeted, so if you're observing it from outside the shadow tree, like the tooltip listener does, then the topmost shadow host is what you see.

Can you give me some concrete STR of a tooltip not showing up or a test failing or something like with your patch that that I could debug?

Comment 12

[alexander :surkov (:asurkov)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

Honestly I'm not sure how the tooltip logic should be modified to make tooltips work. Also having <tabs> as an event target of mouse move over tab's shadow DOM icon is confusing, because <tab> is an explicit child of <tabs>. Either I don't understand what event target is or there's some eventing bug :)

Event.target is retargeted, so if you're observing it from outside the shadow tree, like the tooltip listener does, then the topmost shadow host is what you see.

Can you give me some concrete STR of a tooltip not showing up or a test failing or something like with your patch that that I could debug?

I have updated the patches, now it is a version where shadow content is used. I can see a tooltip issue when running browser/base/content/test/tabs/browser_audioTabIcon.js test.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I took a look at this. I can indeed see the issue. The tooltipNode is the tabs instead of the tab, but that's because you're hitting the arrowscrollbox behind the tab bar, not a tab:

https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/browser/base/content/tabbrowser.xml#20

In general, this patch seems to need a bunch more work. There's a lot of CSS that applies to tabs right now that doesn't apply if you stash the tabs into a shadow root.

You should move all the tab-specific CSS into the shadow root. Probably using :host(..) rules to migrate the tab selectors, and normal rules for the rest of the content inside the tab.

Comment 14

[alexander :surkov (:asurkov)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

I took a look at this. I can indeed see the issue. The tooltipNode is the tabs instead of the tab, but that's because you're hitting the arrowscrollbox behind the tab bar, not a tab:

it's weird, because the test moves the mouse over a tab icon, and event target shouldn't depend on applied styles

https://searchfox.org/mozilla-central/rev/1b2636e8517aa48422ed516affe4d28cb7fa220a/browser/base/content/tabbrowser.xml#20

In general, this patch seems to need a bunch more work. There's a lot of CSS that applies to tabs right now that doesn't apply if you stash the tabs into a shadow root.

You should move all the tab-specific CSS into the shadow root. Probably using :host(..) rules to migrate the tab selectors, and normal rules for the rest of the content inside the tab.

you're right, it requires some effort to adjust cross shadow DOM styling like:

#tabbrowser-tabs:not([movingtab]) > .tabbrowser-tab > .tab-stack > .tab-background[selected="true"]:-moz-lwtheme {

might be worth to give a try to explicit content again.

Comment 15

[Brian Grinstead [:bgrins]]

(In reply to alexander :surkov (:asurkov) from comment #14)

you're right, it requires some effort to adjust cross shadow DOM styling like:

#tabbrowser-tabs:not([movingtab]) > .tabbrowser-tab > .tab-stack > .tab-background[selected="true"]:-moz-lwtheme {

This isn't possible right now. CSS Shadow Parts will let us do that (to be implemented for chrome in https://bugzilla.mozilla.org/show_bug.cgi?id=1505489).

Comment 16

[alexander :surkov (:asurkov)]

Attachment: Bug 1519514 - make sure document.l10n is initialized before triggering conext menu over a tab in browser_ext_menus_activeTab.js test

Comment 17

[alexander :surkov (:asurkov)]

Attachment: Bug 1519514 - make xul/mac-tab-toolbar.xul test running under chrome privileges

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fc479e4e17f2
make sure document.l10n is initialized before triggering conext menu over a tab in browser_ext_menus_activeTab.js test r=Gijs

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8858cc62fe60
make xul/mac-tab-toolbar.xul test running under chrome privileges r=bgrins

Comment 20

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/fc479e4e17f2
https://hg.mozilla.org/mozilla-central/rev/8858cc62fe60

Comment 21

[alexander :surkov (:asurkov)]

so far there are two performance failing tests [1]:

• performance/browser_appmenu.js [2]:
  TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_appmenu.js | unexpected changed rect: ({x1:0, x2:223, y1:0, y2:32, w:224, h:33}), window width: 1280 -
  TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_appmenu.js | should have 0 unknown flickering areas - Got 1, expected 0
• performance/browser_startup_flicker.js [3]
  TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_startup_flicker.js | unexpected changed rect: ({x1:0, x2:223, y1:0, y2:32, w:224, h:33}), window width: 1280 -
• TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_startup_flicker.js | should have 0 unknown flickering areas - Got 1, expected 0

Any ideas/hints what these failures are about and how to debug these tests?

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=f76f45b9de59f78c7b2c8dcf069d646e7e2c2f4c&selectedJob=242139536
[2] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=242139536&repo=try&lineNumber=2323
[3] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=242140703&repo=try&lineNumber=2991

Comment 22

[Brian Grinstead [:bgrins]]

Curious if you drop delayConnectedCallback if the errors change / go away (https://hg.mozilla.org/try/rev/fe8a60d5f24c2a61148cad73948666337e8e08d7#l3.769). That early return is to avoid XBL construction before layout, but just glancing at the content in this.fragment none of those seem to have XBL attached so perhaps we could drop that if it helps.

Comment 23

[alexander :surkov (:asurkov)]

(In reply to Brian Grinstead [:bgrins] from comment #22)

Curious if you drop delayConnectedCallback if the errors change / go away (https://hg.mozilla.org/try/rev/fe8a60d5f24c2a61148cad73948666337e8e08d7#l3.769). That early return is to avoid XBL construction before layout, but just glancing at the content in this.fragment none of those seem to have XBL attached so perhaps we could drop that if it helps.

it was a remedy indeed for performance/browser_startup_flicker.js

performance/browser_appmenu.js seems feel well now with a couple more changes, https://treeherder.mozilla.org/#/jobs?repo=try&revision=07079539fa3fdf05f5ca223cf9be7e20e1c542cc

Comment 24

[alexander :surkov (:asurkov)]

Attachment: Bug 1519514 - convert tabbrowser-tab binding to a Custom Element, r=bgrins

Comment 25

[alexander :surkov (:asurkov)]

there are performance/browser_appmenu.js and performance/browser_tabopen.js failures, which appear to be intermittent ones, however they appear quite often (see https://treeherder.mozilla.org/#/jobs?repo=try&revision=fae8bd4853aae30e719509f86da8561f0f9ee149&selectedJob=242419494)

here's a sample log [3] of performance/browser_appmenu.js test failing. The log contains two images. The second one looks ok, while the first one has a tab of wrong color. If I halt the test right after it fails, then the tab looks ok. I'm not sure how to investigate this test failure further, so any advice/hint is welcome. Cc'ing Florian for ideas.

https://taskcluster-artifacts.net/CVoSnYWiQ765p9tzcksSeQ/0/public/logs/live_backing.log

Comment 26

[Florian Quèze [:florian]]

(In reply to alexander :surkov (:asurkov) from comment #25)

If I halt the test right after it fails, then the tab looks ok.

Makes sense, as the test fails when comparing what got painted and it's the previous paint that was incorrect.

I'm not sure how to investigate this test failure further, so any advice/hint is welcome. Cc'ing Florian for ideas.

Given that this seems to happen on Linux, you might have a chance to debug this with rr.

Another idea is to try to capture a profile of the problem, and see where the paint markers are in the profile compared to other code execution.

Both of these ideas would be way easier to use if you manage to reproduce locally. If there's no way to reproduce, I might be able to help you modify the test so that it uploads a profile.

Comment 27

[alexander :surkov (:asurkov)]

I can reproduce a problem locally on os x. However I see the tests are failing with and without the patches, i.e. the tests fail too on a fresh trunk build. Not sure if this is the same problem, because captured screenshots are different. I guess I could try to debug it, but I have no idea where to set a breakpoint and what to look at. Any pointers or help will be useful.

If the problem can be investigated by capturing and inspecting a profile, then I'd be curious to get more details on it as well. Honestly I have no idea what paint markers are.

Comment 28

[Florian Quèze [:florian]]

(In reply to alexander :surkov (:asurkov) from comment #27)

If the problem can be investigated by capturing and inspecting a profile, then I'd be curious to get more details on it as well. Honestly I have no idea what paint markers are.

Here is a profile of opening a tab that I just captured on my local os x build: https://perfht.ml/2L03qna

The "RefreshDriverTick" markers indicate when we are going to refresh what's displayed. The "Rasterize" markers (visible in green in the timeline at the top) are usually a good approximation of when we paint. Seeing which code runs between these markers might give you a hint about what's happening. Looking at the invalidation stacks in the tooltips of the light blue 'Styles' markers might also give a hint about what happened before the paints.

Comment 29

[alexander :surkov (:asurkov)]

(In reply to Florian Quèze [:florian] from comment #28)

Here is a profile of opening a tab that I just captured on my local os x build: https://perfht.ml/2L03qna

The "RefreshDriverTick" markers indicate when we are going to refresh what's displayed. The "Rasterize" markers (visible in green in the timeline at the top) are usually a good approximation of when we paint. Seeing which code runs between these markers might give you a hint about what's happening. Looking at the invalidation stacks in the tooltips of the light blue 'Styles' markers might also give a hint about what happened before the paints.

Does profile indicate somewhere which part is problematic? If not, then is it possible to link a specific failure in a test with profile's timeline? Also if possible (and make sense), then could you attach a non-failing profile as well to be able compare the profiles, perhaps it could also indicate which part is problematic one.

Looking at screenshots in the profile, I see that 1.35 is a weird one: a first tab looks inactive, but the second one is not yet open, and also 1.39/40 look weird, a second tab size was changed between these screenshots. Am I heading in the right direction?

Comment 30

[Florian Quèze [:florian]]

I didn't try to apply your patch or run a test, this was just a profile of pressing Cmd+t in a local build.

Comment 31

[alexander :surkov (:asurkov)]

(In reply to Florian Quèze [:florian] from comment #30)

I didn't try to apply your patch or run a test, this was just a profile of pressing Cmd+t in a local build.

oops, and no failures for you? So this is a no-bugs profile? :) How do you capture profiles? Any special build? I could try to capture failing profile locally and see the diff.

Comment 32

[alexander :surkov (:asurkov)]

Similar to bug 1547341, delaying browser_appmenu.js and tabopen.js tests helps [1] - the tests are green, which suggests that UI is doing something, that was started before the test, but finished after the test was started, and that something interferes with tests results.

If no timeout, then the failures are:

• tabopen.js claims an unexpected email icon in an address bar [2]
• browser_appmenu.js (which tests an application menu on the right as the test name says) reports a tab [3]

You can use https://mozflicker.000webhostapp.com/ tool to visualize those logs.

In summary, the patches definitely affect on UI drawing, however the failures don't seem directly related: 1) address bar failure for tabs testing and 2) tab failure for application menu testing. So either, we can whitelist those failure (see exceptions section in the test) or we can come with solution to delay tests running until the initial drawing is complete.

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=560c5bdc55231145103e64450588ba1757779585
[2] https://taskcluster-artifacts.net/MoAK9itCTO-s2CeUpgu8Dg/0/public/logs/live_backing.log
[3] https://taskcluster-artifacts.net/SadtaoR4QAG-SUoRXF-4_Q/0/public/logs/live_backing.log
[4] https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_tabopen.js#72

Comment 33

[alexander :surkov (:asurkov)]

Attachment: Bug 1519514 - whitelist tabopen.js and appmenu.js flicker tests

Comment 34

[Florian Quèze [:florian]]

(In reply to alexander :surkov (:asurkov) from comment #32)

All the failures discussed in this comment seem related to in progress CSS transitions that aren't finished when the next test starts. Emilio, is there an existing way to check if any CSS transition is currently in progress in a browser window? If not, how much effort would it take to add a chrome-only API that returns a promise that would resolve once all pending CSS transitions have completed?

Comment 35

[Emilio Cobos Álvarez (:emilio)]

You should be able to implement that API already listening for transitionstart, transitionend and transitioncancel events, right? Assuming this is for testing only, something like this could work:

const gTrackedTransitions = new Set();
function transitionEventKey(e) {
  return { target: e.target, pseudo: e.pseudoElement, prop: e.propertyName };
}

window.addEventListener("transitionstart", function(e) {
  gTrackedTransitions.add(transitionEventKey(e))
});


So something like:

Comment 36

[Emilio Cobos Álvarez (:emilio)]

Err, sorry, can't edit the above comment for some reason, posted too early. But hopefully something like that should work.

Comment 37

[Emilio Cobos Álvarez (:emilio)]

Oh, document.getAnimations() may just be what you want, and the Animation objects have finish and cancel events.

So something like this will wait for all already-running animations to finish. It assumes no other animations start, but that's something you could handle anyways without that much extra trouble:

function waitForAllOutstandingAnimations() {
  return new Promise(resolve => {
    let animations = document.getAnimations();
    let pendingAnimations = animations.length;
    if (!pendingAnimations) {
      resolve();
      return;
    }
    for (const animation of animations) {
      for (const eventName of ["cancel", "finish"]) {
        animation.addEventListener(eventName, function() {
          if (--pendingAnimations)
            return;
          resolve();
        }, false);
      }
    }
  });
}

Comment 38

[Emilio Cobos Álvarez (:emilio)]

So Florian noticed that when he could repro the failures, document.getAnimations().length is zero. This is because the transitions are happening in a shadow tree.

Birtles, document.getAnimations() is implemented right now as basically document.documentElement.getAnimations({ subtree: true }) which obviously doesn't handle Shadow DOM very gracefully...

Was this interaction with Shadow DOM thought about? Should Element.getAnimations() and such have a composed: true or something like that which also returns animations inside open shadow trees?

In any case implementing something like that as ChromeOnly for now seems trivial.

Comment 39

[alexander :surkov (:asurkov)]

Attachment: transition events idea

Here's Emilio's idea. It doesn't help. It seems there's something besides transitions. Is getAnimations a different thing?

Comment 40

[Brian Birtles (:birtles)]

Yep, this is https://github.com/w3c/csswg-drafts/issues/2058. In particular, the last two comments.

Once you have the Animation objects returned by getAnimations() you don't need to mess around with cancel and finish events, just wait on the finished promise (it will reject if the animation is canceled):

await Promise.all(elem.getAnimations({ composed: true }).map(animation => animation.finished));

For anonymous content, we have some rather awkward code in tabbrowser.js for this.

Comment 41

[Emilio Cobos Álvarez (:emilio)]

Yeah, also apparently the transition that Florian was seeing was the scrollbar opacity transition on mac.

Comment 42

[Brian Birtles (:birtles)]

(Forgot to clear the needinfo due to mid-air conflict.)

Emilio, if you have any thoughts about Anne's comments on shadow DOM boundaries I'd be glad to hear them in https://github.com/w3c/csswg-drafts/issues/2058. I'm really ignorant about what's supposed to be possible with, e.g. open vs closed shadow roots.

Comment 43

[Florian Quèze [:florian]]

Here is the profile with symbols that led me in the Mac scrollbar opacity transition direction: https://perfht.ml/2H1fAqM

I think this was a red herring, as the tabopen test still fails for me locally if I make the scrollbars always visible from the Mac system settings.

But I was wondering where we have a scrollbar and why. I wondered if that could be related to the "EXPECTED-FAIL the urlbar placeolder moves up and down by a few pixels" intermittent failures we already had to whitelist before.

I wondered if that could be related to the Marionette UI which adds an icon in the urlbar, so I tried adding document.documentElement.removeAttribute("remotecontrol"); in the test. That removed the Marionette UI, but didn't help with the failures either.

Comment 44

[Florian Quèze [:florian]]

https://perfht.ml/2H40mky is a profile of the tabopen test failing, with scrollbars set to always visible, and the remotecontrol UI removed. The view is focused on what happens between the first and second screenshots captured by the test. I don't know what could change the forward and reload buttons there.

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2cd983857de6
convert tab binding to a Custom Element, r=bgrins
https://hg.mozilla.org/integration/autoland/rev/858b9456eb3c
hg copy tabbrowser.xml to tabbrowser-tabs.js to preserve history for tab binding conversion to a Custom Element, r=bgrins
https://hg.mozilla.org/integration/autoland/rev/8488d800a785
convert tabbrowser-tab binding to a Custom Element, r=aswan
https://hg.mozilla.org/integration/autoland/rev/485c2c76fab6
whitelist tabopen.js and appmenu.js flicker tests r=florian

Comment 46

[Cosmin Sabou [:CosminS]]

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception&searchStr=browser%2Cchrome&fromchange=1fca3309313362e83f3012a488e1bd1d3ff3bc9d&tochange=53e0a08b3768a4affa0733abb3b84795f8baf1e4&group_state=expanded&selectedJob=248896092

Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248896092&repo=autoland&lineNumber=3716
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248892023&repo=autoland&lineNumber=21705
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248896689&repo=autoland&lineNumber=1331
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248896674&repo=autoland&lineNumber=2045

Backout link: https://hg.mozilla.org/integration/autoland/rev/53e0a08b3768a4affa0733abb3b84795f8baf1e4

07:17:34 INFO - TEST-START | browser/components/extensions/test/browser/test-oop-extensions/browser_ext_contextMenus.js
07:17:34 INFO - GECKO(8372) | [Parent 9016, Gecko_IOThread] WARNING: file z:/task_1559106467/build/src/ipc/chromium/src/base/process_util_win.cc, line 160
07:17:47 INFO - GECKO(8372) | [NPAPI 6180, Chrome_ChildThread] WARNING: pipe error: 109: file z:/task_1559106467/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 341
07:17:47 INFO - GECKO(8372) | [NPAPI 6180, Chrome_ChildThread] WARNING: pipe error: 109: file z:/task_1559106467/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 341
07:17:47 INFO - GECKO(8372) | [NPAPI 6180, Chrome_ChildThread] WARNING: pipe error: 109: file z:/task_1559106467/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 341
07:17:53 INFO - GECKO(8372) | console.info: services.settings: Initialize Remote Settings
07:18:19 INFO - TEST-INFO | started process screenshot
07:18:19 INFO - TEST-INFO | screenshot: exit 0
07:18:19 INFO - Buffered messages logged at 07:17:34
07:18:19 INFO - Entering test bound
07:18:19 INFO - Console message: [JavaScript Error: "remote browser crashed while on http://mochi.test:8888/browser/browser/components/extensions/test/browser/context.html
07:18:19 INFO - " {file: "chrome://mochikit/content/mochitest-e10s-utils.js" line: 8}]
07:18:19 INFO - e10s_init/<@chrome://mochikit/content/mochitest-e10s-utils.js:8:8
07:18:19 INFO - EventListener.handleEvente10s_init@chrome://mochikit/content/mochitest-e10s-utils.js:6:10
07:18:19 INFO - testInit@chrome://mochikit/content/browser-test.js:105:5
07:18:19 INFO - setTimeout handler@chrome://mochikit/content/browser-test.js:23:1
07:18:19 INFO - loadChromeScripts@jar:file:///C:/Users/task_1559112155/AppData/Local/Temp/tmp4v0c68.mozrunner/extensions/[e-mail]!/api.js:13:25
07:18:19 INFO - loadMochitest@jar:file:///C:/Users/task_1559112155/AppData/Local/Temp/tmp4v0c68.mozrunner/extensions/[e-mail]!/api.js:112:3
07:18:19 INFO - @Z:\task_1559112155\build\tests\mochitest\runtests.py:1783:5
07:18:19 INFO - @Z:\task_1559112155\build\tests\mochitest\runtests.py:1784:8
07:18:19 INFO - evaluate.sandbox/promise<@chrome://marionette/content/evaluate.js:128:10
07:18:19 INFO - evaluate.sandbox@chrome://marionette/content/evaluate.js:106:17
07:18:19 INFO - GeckoDriver.prototype.execute_@chrome://marionette/content/driver.js:1029:28
07:18:19 INFO - async*GeckoDriver.prototype.executeScript@chrome://marionette/content/driver.js:911:29
07:18:19 INFO - despatch@chrome://marionette/content/server.js:289:40
07:18:19 INFO - execute@chrome://marionette/content/server.js:262:16
07:18:19 INFO - onPacket/<@chrome://marionette/content/server.js:235:20
07:18:19 INFO - onPacket@chrome://marionette/content/server.js:236:9
07:18:19 INFO - _onJSONObjectReady/<@chrome://marionette/content/transport.js:492:20
07:18:19 INFO -
07:18:19 INFO - Buffered messages finished
07:18:19 INFO - TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/test-oop-extensions/browser_ext_contextMenus.js | Test timed out -
07:18:19 INFO - GECKO(8372) | MEMORY STAT | vsize 2104342MB | vsizeMaxContiguous 65110730MB | residentFast 384MB | heapAllocated 138MB
07:18:19 INFO - TEST-OK | browser/components/extensions/test/browser/test-oop-extensions/browser_ext_contextMenus.js | took 45059ms
07:18:19 INFO - Not taking screenshot here: see the one that was previously logged
07:18:19 INFO - TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/test-oop-extensions/browser_ext_contextMenus.js | Found a tab after previous test timed out: http://mochi.test:8888/browser/browser/components/extensions/test/browser/context.html -
07:18:19 INFO - checking window state

Comment 47

[alexander :surkov (:asurkov)]

(In reply to Cosmin Sabou [:CosminS] from comment #46)

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception&searchStr=browser%2Cchrome&fromchange=1fca3309313362e83f3012a488e1bd1d3ff3bc9d&tochange=53e0a08b3768a4affa0733abb3b84795f8baf1e4&group_state=expanded&selectedJob=248896092

I don't see failing tests on this link for the push - only one intermittent failure, https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception&searchStr=browser%2Cchrome&group_state=expanded&revision=485c2c76fab66f5f953c3b336b8d149d53ff93b0. How can I see the failures?

Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248896092&repo=autoland&lineNumber=3716
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248892023&repo=autoland&lineNumber=21705
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248896689&repo=autoland&lineNumber=1331
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=248896674&repo=autoland&lineNumber=2045

these are 3 different failures: /browser_scrollPositionsReaderMode.js, browser_bug852909.js and browser_ext_contextMenus.js. So we deal here with 3 different failures right?

Comment 48

[Cosmin Sabou [:CosminS]]

Alexander, on a second look through the failures, they look like all are related to the backout of Bug 1554063. Please let me reland and will see if new failures arise. Sorry for the trouble., was confused by the other backout.

Comment 49

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9aa56223938b
convert tab binding to a Custom Element, r=bgrins
https://hg.mozilla.org/integration/autoland/rev/555ca6176088
hg copy tabbrowser.xml to tabbrowser-tabs.js to preserve history for tab binding conversion to a Custom Element, r=bgrins
https://hg.mozilla.org/integration/autoland/rev/89b0dcdb08b1
convert tabbrowser-tab binding to a Custom Element, r=aswan
https://hg.mozilla.org/integration/autoland/rev/77a13995b6ab
whitelist tabopen.js and appmenu.js flicker tests r=florian

Comment 50

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/9aa56223938b
https://hg.mozilla.org/mozilla-central/rev/555ca6176088
https://hg.mozilla.org/mozilla-central/rev/89b0dcdb08b1
https://hg.mozilla.org/mozilla-central/rev/77a13995b6ab

Comment 51

[Dão Gottwald [:dao]]

FWIW, I would have preferred to be looped in here.

Comment 52

[Jorg K (CEST = GMT+2)]

Any objection to moving this to mozilla69 since the main part landed on 2019-05-29?