Closed Bug 1384358 Opened 2 years ago Closed 2 years ago
_focus _steal _from _chrome _during _mousedown .js | The input element isn't active element: button=0 - "body" == "will Be Focused" -
In the last 7 days there have been 45 failures. Most of the failures occur on the linux x64 platform. There are also some failures that occur on linux and windows 7 platforms and very low number (1 to 3 failures) on other platforms like: linux32-stylo-disabled, linux64-stylo-disabled, windows10-64-stylo-disabled, windows7-32-stylo-disabled, windows7-32-nightly. The failures mostly occur on the opt build type, but there are some on pgo too and a single failure on debug. :overholt, could you please take a look?
Nika touched this patch a year or so ago so maybe has some ideas :)
Flags: needinfo?(overholt) → needinfo?(nika)
Priority: -- → P2
Previously this was safe, as the synthesized mouse event would be processed in the child process, updating the focus state, in order - before the content process would try to check its focus state. Now, thanks to multiple event queues work, this isn't guaranteed. This patch just adds retrying to the logic, so we retry up to 10 times, 100ms apart. This should ensure that we don't incorrectly detect a test failure intermittently. MozReview-Commit-ID: J4uzl9jeafC
Attachment #8927951 - Flags: review?(enndeakin)
Comment on attachment 8927951 [details] [diff] [review] Avoid racy check of focus manager in content process Review of attachment 8927951 [details] [diff] [review]: ----------------------------------------------------------------- Seems fine for now, but in the long run we probably want 1240052 to be implemented.
Attachment #8927951 - Flags: review?(enndeakin) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/07d87a46d621 Avoid racy check of focus manager in content process, r=enndeakin
You need to log in before you can comment on or make changes to this bug.