Open Bug 951575 Opened 7 years ago Updated 7 years ago

CAPS does not work in Nightly(Holly)29.0a1


(Core :: Security: CAPS, defect)

29 Branch
Windows 7
Not set



Tracking Status
firefox28 --- unaffected
firefox29 --- affected


(Reporter: alice0775, Unassigned)



(Keywords: regression)

Steps To Reproduce:
1. Append the followings to user.js in your profile.

user_pref("capability.policy.policynames", "nofocus");
user_pref("capability.policy.nofocus.sites", "");
user_pref("capability.policy.nofocus.HTMLInputElement.focus", "noAccess");

2. Start Nightly
3. Open

Actual Results:
<input> element is automatically focused when a page loads. .

Expected Results:
Not focused.

Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131213184052
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131213191653

Triggered by: Bug 913734

Probably, other CAPS policy also do not work.
This is intentional. See bug 913734 comment #8. CAPS is dead.
Then, Firefox will die, too :(

BTW, is alternative method available?
If not, CAPS should be reverted
HTMLInputElement.prototype.wrappedJSObject.focus = function() {};
in the user-script? (It worked for me.)
But it would be danger if content can replace HTMLInputElement.prototype.focus before the user-script.
Better idea is welcome.
How could this have possibly worked?  WebIDL bindings don't call into CAPS, so the user.js in comment 0 shouldn't have affected whether focus() can be called.  Per-property CAPS checks have been dead for a long time now...

And indeed, if I build from m-c rev 681ab70f6707 and try to follow the steps from comment 0 the textfield ends up focused.
You need to log in before you can comment on or make changes to this bug.