OSX Mojave (10.14) - browser_urlbar_search_legacy.js and browser_urlbar_keyed_search_legacy.js fail
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox69 | --- | fixed |
People
(Reporter: jmaher, Assigned: adw)
References
Details
Attachments
(1 file)
In bug 1528744 we added both browser_urlbar_keyed_search_legacy.js and browser_urlbar_search_legacy.js to be run from:
browser/base/content/test/performance/legacyurlbar/browser.ini
Both of these tests fail when run on osx 10.14
you can see a try push (debug/bc6 opt/bc3):
https://treeherder.mozilla.org/#/jobs?repo=try&searchStr=osx%2Cbrowser&revision=27d8e706de22ac93732dab0733347657e2a6433f
here is the screenshot from debug:
https://taskcluster-artifacts.net/QKEBb9-wRweSdVjrmCuSYA/0/public/test_info/mozilla-test-fail-screenshot_S9iE14.png
here are the failures we see:
TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_urlbar_keyed_search_legacy.js | unexpected reflow at __rebuild@chrome://browser/content/search/search-one-offs.js hit 1 times
TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_urlbar_keyed_search_legacy.js | 1 unexpected reflows - false == true - JS frame :: chrome://mochitests/content/browser/browser/base/content/test/performance/head.js :: reportUnexpectedReflows :: line 200
TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_urlbar_search_legacy.js | unexpected reflow at __rebuild@chrome://browser/content/search/search-one-offs.js hit 1 times
TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_urlbar_search_legacy.js | 1 unexpected reflows - false == true - JS frame :: chrome://mochitests/content/browser/browser/base/content/test/performance/head.js :: reportUnexpectedReflows :: line 200
I assume we can tweak the reflows in the test?
Comment 1•5 years ago
|
||
Are we sure the screen resolution is correct? That's frequently the source of per platform reflow issues?
Reporter | ||
Comment 2•5 years ago
|
||
thanks :standard8 for the comment, let me check.
here is a screenshot from 10.10:
https://taskcluster-artifacts.net/ZCcvmZD1Q6Cy0MAqGFrsBw/0/public/test_info/mozilla-test-fail-screenshot_DhNo1R.png
it looks slightly different, but very similar.
:dividehex- I don't see any reference to resolution in the logs, can you let me know the resolution on 10.10 and 10.14?
Assignee | ||
Comment 3•5 years ago
|
||
This seems straightforward to fix -- either the screen resolution problem or just adding a new unexpected reflow, although if it's the latter it would be nice to know why a new reflow is happening on 10.14.
Assignee | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Just looking at the screenshots, the resolution doesn't seem to be an issue. Not sure about that tour notification, though I'd be very surprised if that's causing issues...
Comment 5•5 years ago
|
||
(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #2)
:dividehex- I don't see any reference to resolution in the logs, can you let me know the resolution on 10.10 and 10.14?
The screen resolution should be the same between 10.10 and 10.14. The datacenter mac minis all have EDID devices connected to their hdmi ports to simulate having a connected monitor with a resolution of 1600x1200. The only situation where the resolution could be different would be if it changes programmatically or the EDID device has failed. You can check this by executing the system_profiler as the cltbld user:
[cltbld@t-mojave-r7-470.test.releng.mdc1.mozilla.com ~]$ /usr/sbin/system_profiler SPDisplaysDataType
Graphics/Displays:
Intel Iris:
Chipset Model: Intel Iris
Type: GPU
Bus: Built-In
VRAM (Dynamic, Max): 1536 MB
Vendor: Intel
Device ID: 0x0a2e
Revision ID: 0x0009
Metal: Supported, feature set macOS GPUFamily1 v4
Displays:
Display:
Resolution: 1600 x 1200 (UXGA - Ultra eXtended Graphics Array)
UI Looks like: 1600 x 1200 @ 60 Hz
Framebuffer Depth: 24-Bit Color (ARGB8888)
Display Serial Number: 1600x1200 60
Main Display: Yes
Mirror: Off
Online: Yes
Rotation: Supported
Automatically Adjust Brightness: No
As for the tour notification, I don't think it is easily disabled or dismissed. Although, if it is the source of the problem and it can't be worked around, I can dig deeper on how to remove it.
Assignee | ||
Comment 6•5 years ago
|
||
As I was working on these, I realized they're legacy awesomebar tests ("legacy" is in their names, d'oh), so it's not a big deal to keep them disabled, and this shouldn't be a P1. But anyway, there's one initial expected reflow in these tests, but it's disabled/commented-out on macOS. For whatever reason, this reflow happens on 10.14, as it does on other platforms.
This first try push just includes the reflow on 10.14: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f3c6634f22315a881ed7a50702d437d84e24a433
I want to do another push that simplifies the logic a little more. Right now the logic includes a check for debug builds, but the check isn't quite the same in both of these tests, so I wonder whether it's really necessary.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Redo of the previous push, since macOS versions are specified in terms of Darwin, looks like: https://treeherder.mozilla.org/#/jobs?repo=try&revision=805cffee35c8786b285ffbef09e0ffcaac2cef3a
Assignee | ||
Comment 8•5 years ago
|
||
Looks good. Here's the other push with simplified logic for including the first reflow: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8558d9ec29bd4d6ce7372c182ff3cc8c7d6d2275
Assignee | ||
Comment 9•5 years ago
|
||
This includes the previously excluded initial expected reflow on macOS 10.14. That reflow is already expected on other platforms, and it seems to be necessary on 10.14, too. This also removes the DEBUG checks. Those checks are different between these two tests, so I had a hunch that maybe they aren't actually necessary, and they seem not to be. Here's a try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8558d9ec29bd4d6ce7372c182ff3cc8c7d6d2275&selectedJob=247137299
Assignee | ||
Comment 10•5 years ago
|
||
That last try run shows failures in browser_urlbarStop.js, which I thought I fixed in bug 1485288, sigh: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8558d9ec29bd4d6ce7372c182ff3cc8c7d6d2275&selectedJob=247137299
Comment 11•5 years ago
|
||
Pushed by dwillcoxon@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/70e638c59816 Fix browser_urlbar_search_legacy.js and browser_urlbar_keyed_search_legacy.js failures on macOS 10.14 Mojave. r=Standard8
Comment 12•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Description
•