Closed Bug 1390000 Opened 2 years ago Closed 2 years ago

testInputConnection is going to permafail when Gecko 57 merges to Beta on 2017-09-20

Categories

(Firefox for Android :: Keyboards and IME, defect)

55 Branch
Unspecified
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 57
Tracking Status
firefox57 - verified

People

(Reporter: RyanVM, Assigned: jchen)

References

Details

Attachments

(1 file)

[Tracking Requested - why for this release]: Permafailing tests after the next uplift.

Jan, I see that you touched code related to this in bug 1266683. Can you please take a look at this? Thanks!

https://treeherder.mozilla.org/logviewer.html#?job_id=122807431&repo=try

TEST-UNEXPECTED-FAIL | testInputConnection | Can reuse composition in Gecko - got <===, expected <=|=|=|
PROCESS-CRASH | testInputConnection | java-exception junit.framework.AssertionFailedError: TEST-UNEXPECTED-FAIL | testInputConnection | Can reuse composition in Gecko - got <===, expected <=|=|=| at junit.framework.Assert.fail(Assert.java:50)
Flags: needinfo?(jh+bugzilla)
As far as I can tell, this means that some "selectionchange" events go missing (https://dxr.mozilla.org/mozilla-central/rev/5322c03f4c8587fe526172d3f87160031faa6d75/mobile/android/tests/browser/robocop/robocop_input.html#64). Bug 1266683 shouldn't have any influence there, and indeed the test is failing even with it backed out again (https://treeherder.mozilla.org/#/jobs?repo=try&revision=a82a9b7a9c32dd5fdeec5cef976a8e76c67ce988).

My best guess would be that there's something wonky around the "dom.select_events.textcontrols.enabled" pref (https://dxr.mozilla.org/mozilla-central/search?q=dom.select_events.textcontrols.enabled&redirect=false) now - it's disabled by default on anything other than Nightly and maybe for some reason our attempts to enable it (https://dxr.mozilla.org/mozilla-central/rev/5322c03f4c8587fe526172d3f87160031faa6d75/mobile/android/tests/browser/robocop/robocop_input.html#32) no longer work.

Hazarding a guess this is probably related to bug 1386468.
Blocks: 1386468
Flags: needinfo?(jh+bugzilla) → needinfo?(ehsan)
There is nothing wonky around the pref, the pref works just fine.  Your test is setting is way too late and it is taking no effect.

Generally, the correct way to set prefs for tests is to set them *before* the page is loaded, not after.  In other words, you need to restructure the test to make it first set the pref, then load an iframe that loads the page which has the <input> element being tested.

Here, specifically, the problem is that the place the side effect of the pref is read is here <https://searchfox.org/mozilla-central/rev/e5b13e6224dbe3182050cf442608c4cb6a8c5c55/layout/generic/nsFrameSelection.cpp#739> and it is triggered when the test forces the instantiation of the underlying editor object <https://searchfox.org/mozilla-central/rev/e5b13e6224dbe3182050cf442608c4cb6a8c5c55/mobile/android/tests/browser/robocop/robocop_input.html#102>.  So by the time you set the pref, the change of registering the SelectionChangeListener is already passed, and no selectionchange event will get dispatched.
Flags: needinfo?(ehsan)
Assignee: nobody → nchen
Status: NEW → ASSIGNED
Set prefs in testInputConnection itself, before we load
robocop_input.html, so the page uses new pref values.
Attachment #8897548 - Flags: review?(esawin)
Attachment #8897548 - Flags: review?(esawin) → review+
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5e5715c50691
Set prefs before loading input test page. r=esawin
https://hg.mozilla.org/mozilla-central/rev/5e5715c50691
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Status: RESOLVED → VERIFIED
This is fixed, no need to track it.
You need to log in before you can comment on or make changes to this bug.