Comment on attachment 8973850[details][diff][review]
focus_crash.diff
[Security approval request comment]
How easily could an exploit be constructed based on the patch?
The patch does pinpoint what kind of issue is being fixed.
Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
The commit message could be
-m "Bug 1459693, ensure the right anonymous element is focused when calling input.focus(), r=mccr8"
Which older supported branches are affected by this flaw?
all
Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
The code seems to be untouched since 2011, so the same patch should apply on supported branches
How likely is this patch to cause regressions; how much testing does it need?
Very unlikely to cause regressions. Just keeping an object alive a bit longer.

Comment on attachment 8973850[details][diff][review]
focus_crash.diff
Under the assumption that this is going to have a delayed landing, I'm clearing the uplift requests for now so they're not inactionably on the request radar for the next few weeks.

Comment on attachment 8973850[details][diff][review]
focus_crash.diff
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
this is sec-crit
User impact if declined:
security sensitive crash
Fix Landed on Version:
62
Risk to taking this patch (and alternatives if risky):
should be very safe
String or UUID changes made by this patch:
NA
[Feature/Bug causing the regression]:
old stuff
[Is this code covered by automated tests?]:
nope
[Has the fix been verified in Nightly?]:
not yet
[Is the change risky?]:
nope
[Why is the change risky/not risky?]:
just using RefPtr and not raw pointer.

sec-high seems more appropriate here. All the uses in CheckIfFocusable() are reads and not writes. If somehow you managed to thread through this function with an appropriate answer the deleted objection might be used later but it's currently not as straightforward a path to exploitability as we usually require for sec-critical.

For ESR 60, I used an ASAN fuzzy build downloaded from https://tools.taskcluster.net/index/gecko.v2.mozilla-esr60.latest.firefox/linux64-fuzzing-asan-opt .
The testcase from comment 0 is not working (the two input boxes are not displayed) and I am getting the following error in console:
JavaScript error: chrome://xbl-marquee/content/xbl-marquee.xml, line 541: TypeError: this.outerDiv is undefined
1529587265928 addons.update-checker WARN onUpdateCheckComplete failed to parse update manifest: [Exception... "Update manifest is missing a required addons property." nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/addons/AddonUpdateChecker.jsm :: getRequiredProperty :: line 461" data: no] Stack trace: getRequiredProperty()@resource://gre/modules/addons/AddonUpdateChecker.jsm:461.
Also, I did not reproduce the crash.
The same behavior can be observed on official ESR 60.1.0 build ID 20180621121604.
As for ESR 52, I did not find an ASAN build with fuzzy functions, so I used an asan build and used the DOMFuzz Helper for fuzzy functions. The result is the same as for the ESR 60: the testcase is not working and the crash is not reproducible. The same on latest ESR 52.9.0 build ID 20180621064021.
I'm not sure what the verification criteria is for ESR builds:
1. Testcase does not crash on esr builds
2. Testcase doesn't seem to work on esr builds(the two input boxes are not displayed)
Summing up, I'm not sure how to continue verification on this.