This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
Removes the PluginProvider and NPAPI plugin blocklist handling as part of removing all NPAPI support. This allows us to remove nsIPluginHost.
Differential Revision: https://phabricator.services.mozilla.com/D107148
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
CLOSED TREE
Backed out changeset 7b19f4ed5182 (bug 1681985)
Backed out changeset e77582268ce1 (bug 1681985)
Backed out changeset 386a8b11c127 (bug 1681985)
Before `SharedLibraryInfo::GetInfoForSelf` calls `GetPdbInfo` to parse a module's
PE header, it calls `LoadLibraryEx` to prevent the module from being unloaded
during `GetPdbInfo`. If the module was already unloaded before `LoadLibraryEx`,
however, `LoadLibraryEx` maps the module onto an address different from the original
mapped address, so that `module.lpBaseOfDll` becomes invalid.
This patch is to call `LoadLibraryEx` before `GetModuleInformation` to make sure
`LoadLibraryEx` increments the module's refcount and does not map the module onto
a new address. With this, `module.lpBaseOfDll` is always valid, thus we don't have
to call `VirtualQuery`.
Differential Revision: https://phabricator.services.mozilla.com/D110421
Lastly, we are changing the parts that requires a version bump and bumping the
profiler version in the end. This will require a PR in the front-end for a
version upgrader and changes related to the renaming.
Differential Revision: https://phabricator.services.mozilla.com/D109282
We have two parts in the codebase that we get the browsingContextId.
1) Inside the DOM code with profiler_register_page function whenever a
navigation happens.
2) Inside the profiler recording front-end when we start the profiler. That was
kept as activeBrowsingContextID, and now it's kept as activeTabID.
We are now changing these parts to keep the browserId instead so it directly
corresponds to the tabs. BrowsingContexts are replaced when there is a
cross-group navigation, but BrowserId is being preserved.
Differential Revision: https://phabricator.services.mozilla.com/D109281
This patch is only about renaming the internals of the profiler codebase and
it doesn't touch any parts that requires a backwards compatibility or version
bump.
Differential Revision: https://phabricator.services.mozilla.com/D109280
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
We need it from both FormAutofillHeuristics and CreditCardRuleset, and it would make a circular import otherwise: FormAutofillHeuristics -> CreditCardRuleset -> FormAutofillHeuristics.
Differential Revision: https://phabricator.services.mozilla.com/D100140
It requires including <windows.h>, preventing the inclusion of StackWalk.h
from some places (and upcoming changes will make StackWalk.h included in
more places).
Differential Revision: https://phabricator.services.mozilla.com/D108910
In the case of FramePointerStackwalk, the caller gives a pointer to the
top-most frame to walk from. There isn't really a reason to give a
number of frames to skip, as the right frame pointer could be given in
the first place if that was really necessary. And in practice, it's
hasn't been used so far.
In the case of MozStackWalkThread, the caller presumably doesn't know
what the thread the stack is being walked for is doing, and it would be
a guesswork to pass a valid number of frames to skip. In practice, it's
also not used.
The aSkipFrames is already a footgun on MozStackWalk (and we're going to
change that in bug 1515229), we don't need to keep a footgun on these
other stack walking methods.
Differential Revision: https://phabricator.services.mozilla.com/D108563
In a later bug, ExtractJsFrames will retrieve more information about the JS frames, which will be given to stack walkers in order to resume native sampling past JIT stacks.
Differential Revision: https://phabricator.services.mozilla.com/D108417
Some changes after the previous just-move-the-code refactoring:
- Updated functon comment for clarity.
- Renamed `jsCount` to more precise `jsFramesCount`.
- Moved `samplePosInBuffer` computation to where it's first needed. Bonus: It won't happen anymore if there is no JS stack.
- Construct `jsIter` as first `for` statement, it's clearer that it's the main loop iterator.
- Moved `MAX_JS_FRAMES` checks into the loop body, and only when needed.
- Try to move-from an rvalue reference to the `frame`, instead of `value()` forcing a copy.
- Moved `context` retrieval closer to first use. Same in `MergeStacks`; Note that `aRegisteredThread.GetJSContext()` is only reading a member variable, so it's cheap enough to use it again there if needed, it may even be better overall than storing it in a register or on the stack (if the compiler couldn't optimize it already before).
Differential Revision: https://phabricator.services.mozilla.com/D108416
