After further investigation, the reason of this timeout is that: 1. the "await popupPromise;" at [1] has never returned. 2. the reason why the popupPromise was not resolved is that clicky.onclick has never been trigger. 3. the clicky.onclick is not triggered because the eventTarget found internally in PresShell::HandleEvent() via synthesizeMouseAtCenter(clicky, {}, window) [2] is incorrect. The element that received mousedown/mouseup/onclick is the "HTMLHtmlElement" of this document instead of the "HTMLButtonElement". In addition, if we postpone the call of synthesizeMouseAtCenter() using SimpleTest.executeSoon(), the timeout problem is disappeared. [1] https://searchfox.org/mozilla-central/rev/33c90c196bc405e628bc868a4f4ba29b992478c0/dom/tests/mochitest/general/test_resizeby.html#58 [2] https://searchfox.org/mozilla-central/rev/33c90c196bc405e628bc868a4f4ba29b992478c0/dom/tests/mochitest/general/test_resizeby.html#56

After further investigation, the difference identified so far is the dumped display list in nsLayoutUtils::GetFramesForArea [1] called from PresShell::HandleEvent(): 1. From the PASSED result, we case see complete list that matches the html document in the test case: Event handling --- (2640,3660): BackgroundColor p=0x7f64ab0b0020 f=0x7f64b1f7a158(HTMLScroll(html)(-1)) key=4 bounds(0,0,7680 CanvasBackgroundColor p=0x7f64ab0b0120 f=0x7f64b1f7a0b0(Canvas(html)(-1)) key=15 bounds(0,0,7 BackgroundColor p=0x7f64ab0b0260 f=0x7f64b1f7a908(Block(html)(-1)) key=4 bounds(0,0,76800,524 BackgroundColor p=0x7f64ab0b0360 f=0x7f64b8d1ef00(FlexContainer(body)(2)) key=4 bounds(0,0,76 BackgroundColor p=0x7f64ab0b0460 f=0x7f64ab0e9020(FlexContainer(div)(0) class:container) key= BackgroundColor p=0x7f64ab0b0560 f=0x7f64ab0e90b0(FlexContainer(div)(12) class:frameholder) k BackgroundColor p=0x7f64ab0b0660 f=0x7f64b8d103f8(FrameOuter(iframe src=/tests/dom/tests/moch Border p=0x7f64ab0b0760 f=0x7f64b8d103f8(FrameOuter(iframe src=/tests/dom/tests/mochitest/gen SubDocument p=0x7f64ab0b1560 f=0x7f64b8c07020(Viewport(-1)) key=50 bounds(120,120,76560,52200 BackgroundColor p=0x7f64ab0b0be0 f=0x7f64b8c07158(HTMLScroll(html)(-1)) key=4 bounds(120,12 CanvasBackgroundColor p=0x7f64ab0b0ce0 f=0x7f64b8c070b0(Canvas(html)(-1)) key=15 bounds(120 BackgroundColor p=0x7f64ab0b0e20 f=0x7f64b8c07908(Block(html)(-1)) key=4 bounds(120,120,765 BackgroundColor p=0x7f64ab0b0f20 f=0x7f64b8c079b8(Block(body)(2) id:body) key=4 bounds(600, BackgroundColor p=0x7f64ab0b1020 f=0x7f64b8c07c30(Block(div)(5) id:content) key=4 bounds(60 BackgroundColor p=0x7f64ab0b1120 f=0x7f64b8c07ce0(HTMLButtonControl(button)(1) id:clicky) k ThemedBackground p=0x7f64ab0b1260 f=0x7f64b8c07ce0(HTMLButtonControl(button)(1) id:clicky) ButtonBorderBackground p=0x7f64ab0b1360 f=0x7f64b8c07ce0(HTMLButtonControl(button)(1) id:cl ButtonForeground p=0x7f64ab0b1460 f=0x7f64b8c07ce0(HTMLButtonControl(button)(1) id:clicky) 2. From the TIMEOUT one, the list was ened in Canvas(html): Event handling --- (2640,3660): BackgroundColor p=0x7f3f1af4b020 f=0x7f3f26eba158(HTMLScroll(html)(-1)) key= CanvasBackgroundColor p=0x7f3f1af4b120 f=0x7f3f26eba0b0(Canvas(html)(-1)) ke BackgroundColor p=0x7f3f1af4b260 f=0x7f3f26eba908(Block(html)(-1)) key=4 bou BackgroundColor p=0x7f3f1af4b360 f=0x7f3f26eeaf00(FlexContainer(body)(2)) ke BackgroundColor p=0x7f3f1af4b460 f=0x7f3f1dfb5020(FlexContainer(div)(0) clas BackgroundColor p=0x7f3f1af4b560 f=0x7f3f1dfb50b0(FlexContainer(div)(12) cla BackgroundColor p=0x7f3f1af4b660 f=0x7f3f26ee43f8(FrameOuter(iframe src=/tes Border p=0x7f3f1af4b760 f=0x7f3f26ee43f8(FrameOuter(iframe src=/tests/dom/te SubDocument p=0x7f3f1af4be20 f=0x7f3f252f5020(Viewport(-1)) key=50 bounds(12 BackgroundColor p=0x7f3f1af4bbe0 f=0x7f3f252f5158(HTMLScroll(html)(-1)) ke CanvasBackgroundColor p=0x7f3f1af4bce0 f=0x7f3f252f50b0(Canvas(html)(-1)) Maybe somehow we break the flow between the construction of the frame tree and the window.onload event with the fix in bug 1193394. [1] https://searchfox.org/mozilla-central/rev/33c90c196bc405e628bc868a4f4ba29b992478c0/layout/base/nsLayoutUtils.cpp#3333-3341

The hit test work properly until the frame tree is updated later after "load" event is fired: https://searchfox.org/mozilla-central/source/layout/base/nsDocumentViewer.cpp#1098 Adopt SimpleTest.promiseFocus() to align this test with the others that using synthesizeMouseXxx() methods in EventUtils.js to prevent sending a mouse event in the intermediate state of updating the frame tree.

Comment on attachment 8931581 [details] [diff] [review] (v1) Patch: Fix timeout of test_resizeby.html if new promise scheduling is applied. I guess this is ok. Maybe other option would have been to call loadedResolve() asynchronously after load event.

(In reply to Olli Pettay [:smaug] from comment #3) > I guess this is ok. > Maybe other option would have been to call loadedResolve() asynchronously > after load event. Yes, to call loadedResolve() asynchronously do fix the failure. I choose SimpleTest.promiseFocus() because the test can also be started asynchronously with SimpleTest.executeSoon() after both loaded and focus events are fired which makes more sense to me in mouse event testing after comparing with other tests in dom/event.

Pushed by btseng@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3e5f310f67e8 Fix timeout of test_resizeby.html if new promise scheduling is applied. r=smaug