I've seen at least one test case with this method from domFuzz.
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?
This is defined here: https://github.com/MozillaSecurity/funfuzz/blob/master/dom/extension/content/fuzzPriv.js#L122 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?
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: https://github.com/MozillaSecurity/funfuzz/blob/master/dom/fuzzer/modules/keyboard-events.js
(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.
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: fuzzPriv.ccSlice fuzzPriv.finishCC fuzzPriv.CC fuzzPriv.MP fuzzPriv.forceShrinkingGC fuzzPriv.forceGC fuzzPriv.schedulePreciseShrinkingGC fuzzPriv.schedulePreciseGC fuzzPriv.CCLog fuzzPriv.gczeal Misc Functions: fuzzPriv.zoom fuzzPriv.printToFile fuzzPriv.getMemoryReports fuzzPriv.callDrawWindow fuzzPriv.enableBookmarksToolbar fuzzPriv.disableBookmarksToolbar
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.