Implement trustedKeyEvent in FuzzingFunctions




a year ago
a year ago


(Reporter: mccr8, Unassigned)


(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)




a year ago
I've seen at least one test case with this method from domFuzz.
Priority: -- → P2


a year ago
Assignee: nobody → continuation
What does this actually do? Mark the script created event trusted or that and also dispatch event to widget level code? Latter might be more useful for testing. Either somehow exposing parts of the functionality of DOMWindowUtils or nsITextInputProcessor?

Comment 2

a year ago
This is defined here:
It runs as chrome. Maybe it isn't a realistic thing to have.
yeah, ok, that just dispatches trusted key events, which means it bypasses EventStateManager and such.
So it covers only parts of key event default handling.
It looks like bug 894118 was to track these bugs, but I'm not sure how complete it is. Gary do you know anything about this?


a year ago
Blocks: 894118

Comment 5

a year ago
Yeah, it looks like nothing has been filed against that bug for 4 years, so this probably isn't too high priority. A bug was reported recently (bug 1343642) using it, but it looks like it isn't clear if it is a bug.
(In reply to Jesse Schwartzentruber (:truber) from comment #4)
> It looks like bug 894118 was to track these bugs, but I'm not sure how
> complete it is. Gary do you know anything about this?

It may already have been part of domfuzz, see bug 894118 comment 1 which references:

Comment 7

a year ago
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #6)
> It may already have been part of domfuzz, see bug 894118 comment 1 which
> references:

Yeah, but this bug is about reimplementing that function in fuzzing builds of Firefox itself because domfuzz will stop working once XUL addons no longer work.


a year ago
Assignee: continuation → nobody
API to synsthesize KeyboardEvents via widget won't deprecated even after 57 because that tests a lot in mochitest. If you need such API to WebExtensions, I think that you should request it and the team should declare such dangerous API being allowed only for some special extensions which need to test browser itself (with special privilege?).

BTW, if you need an API to synthesize keyboard event with realistic path, it should be:

* using nsITextInputProcessor to dispatch keyboard events via widget and to share actual dispatching event path, TextEventDispatcher, with actual products.
* not dispatching synchronously, because user input is never handled in the stack after event listener. (Dispatching user input events from event listener may cause impossible situation in some classes.)

Although, nsITextInputProcessor isn't e10s aware (dispatching KeyboardEvent and CompositionEvent via PuppetWidget if you use it in content process).
If we can get this implemented as part of a WebExtension, would it be possible to have the other fuzzPriv functions added as well?

Memory Functions:

Misc Functions:


a year ago
Blocks: 1346339

Comment 10

a year ago
These probably can't be implemented as a WebExtension. Instead, I am adding them to FuzzingFunctions, implementing them in C++. Then a WebExtension could call into those methods, or fuzzers could call them directly.

CC and forceGC are just the same thing as what I implemented in bug 1322400.

I did a search in bugzilla for "fuzzPriv" to try to find test cases to see what has actually ever been used. Actually, just doing a Google search for "fuzzPriv.schedulePreciseShrinkingGC" or whatever is probably more effective. Feel free to file separate bugs for ones that might actually be useful, cc me, and make them blocking bug 1346339. (For instance, IIRC ccSlice only ever found bugs with the ccSlice method, not actual bugs in the CC.) Most of these are probably just a few lines of code, but we should prioritize the useful ones.
You need to log in before you can comment on or make changes to this bug.