Status

()

task
P5
normal
RESOLVED FIXED
6 months ago
14 days ago

People

(Reporter: timdream, Assigned: surkov)

Tracking

(Blocks 2 bugs)

unspecified
mozilla69
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox69 fixed)

Details

(Whiteboard: [xbl-available])

Attachments

(7 attachments, 1 obsolete attachment)

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

Updated

5 months ago
Priority: -- → P5
Assignee

Updated

3 months ago
Assignee: nobody → surkov.alexander
Assignee

Comment 4

3 months ago

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?

Flags: needinfo?(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?

Flags: needinfo?(emilio)
Assignee

Comment 6

3 months ago

(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

Assignee

Comment 7

3 months ago

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

Flags: needinfo?(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.

Flags: needinfo?(emilio)
Assignee

Comment 9

3 months ago

(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

Assignee

Comment 10

3 months ago

ni? from Emilio on comment #9

Flags: needinfo?(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?

Flags: needinfo?(emilio)
Assignee

Comment 12

3 months ago

(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.

Flags: needinfo?(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.

Flags: needinfo?(emilio)
Assignee

Comment 14

2 months ago

(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.

(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 18

2 months ago
Pushed by asurkov@mozilla.com:
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

2 months ago
Pushed by asurkov@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8858cc62fe60
make xul/mac-tab-toolbar.xul test running under chrome privileges r=bgrins

Comment 20

2 months ago
bugherder
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee

Updated

2 months ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 1546332
Assignee

Comment 21

2 months ago

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

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.

Assignee

Comment 23

2 months ago

(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

Attachment #9056698 - Attachment is obsolete: true
Attachment #9056697 - Attachment description: Bug 1519514 - hg copy tabbrowser.xml to tabbrowser-tabs.js to preserve history for tab binding conversion to a Custom Element, r=bgrins → Bug 1519514 - hg copy tabbrowser.xml to tabbrowser-tab.js to preserve history for tab binding conversion to a Custom Element, r=bgrins
Assignee

Comment 25

2 months ago

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

Flags: needinfo?(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.

Flags: needinfo?(florian)
Assignee

Comment 27

2 months ago

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.

Flags: needinfo?(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.

Flags: needinfo?(florian)
Assignee

Comment 29

2 months ago

(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?

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.

Assignee

Comment 31

2 months ago

(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.

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

Comment 32

2 months ago

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

(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?

Flags: needinfo?(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:
Flags: needinfo?(emilio)

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

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);
      }
    }
  });
}

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.

Flags: needinfo?(bbirtles)
Assignee

Comment 39

2 months ago

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

Assignee

Updated

2 months ago
Flags: needinfo?(emilio)

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.

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

Flags: needinfo?(emilio)

(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.

Flags: needinfo?(bbirtles)

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.

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

28 days ago
Pushed by asurkov@mozilla.com:
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

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/mochikit@mozilla.org.xpi!/api.js:13:25
07:18:19 INFO - loadMochitest@jar:file:///C:/Users/task_1559112155/AppData/Local/Temp/tmp4v0c68.mozrunner/extensions/mochikit@mozilla.org.xpi!/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

Flags: needinfo?(surkov.alexander)

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.

Flags: needinfo?(csabou)

Comment 49

28 days ago
Pushed by csabou@mozilla.com:
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

Updated

28 days ago
Type: enhancement → task

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

Regressions: 1555908
Blocks: 1555929
Regressions: 1555943
Blocks: 1555951

Comment 52

14 days ago

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

Target Milestone: mozilla68 → mozilla69
You need to log in before you can comment on or make changes to this bug.