This enables a few of the debugger tests. The first test,
browser_dbg_aaa_run_first_leaktest.js, is intentionally disabled,
because it appears to have a legitimate leak.
This reworks how the Mochitest DOMWINDOW and DOCSHELL leak detector works. Rather than
collecting immediately in the top-level script, it sends a message to all processes
telling them to carry out collections. Each process prints out a message when it has
finished the collections. This message is used by the test harness to decide when windows
and docshells for that process should be have been destroyed.
In non-e10s mode, the shutdown leak detector is only run in the parent process, to work
around various issues with leak detection in the thumbnail process tests.
The regular expression cache for mozpack.path.match was keyed off the
original pattern. However, that variable was mutated as part of the
function and the mutated result was subsequently stored as the cache
key. This effectively resulted in a 0% cache hit rate.
On some tests being written for bug 1132111 which involve a full
filesystem traversal for moz.build files and subsequent execution of
those files, the following timings are indicative of the impact of this
patch.
Before:
real 16.082s
user 14.760s
sys 1.318s
After:
real 6.345s
user 5.085s
sys 1.257s
These code paths should never be reached, since nsPrintingPromptService returns
NS_ERROR_NOT_IMPLEMENTED for ShowProgress.
Bug 1135901 has been filed to remove this dead code entirely.
Part 1 fixed sending referrer information when opening a plain text
"link" in a new tab through the context menu. This patch fixes the same
problem, but for the case of opening in a new window, since we take
slightly different paths through |openLinkIn| for tabs vs. windows.
It turns out that treating null links as being OK for passing along
referrer information means that we now pass referrer information for
plain text "links" that are opened via the context menu. For referrer
information, we should take a much more conservative approach, and
declare that null links are always treated as if they had
rel="noreferrer".
On B2G, the primary frame for tab content was not giving the correct process offset so we revert back to the mechanism we used to have in nsSubdocumentFrame.
Change the PuppetWidget from defining screen coordinates from tab-content-relative to being based on actual screen geometry. PuppetWidgets can have position. In the parent process, the widget has a position and a separate client position (that includes OS window chrome... on Linux and Windows as others have no chrome). In the child process, the widget (non-origin) position, whose calculation compensates for the OS window decoration.
TabParents now register for the MozUpdateWindowPos event on the chrome TopWindowRoot. When the window is moved, the OS widget calls WindowMoved on its listener (the nsWebShellWindow), which sends a MozUpdateWindowPos event.
PuppetWidget::WidgetToScreenOffset now reports proper widget screen location. Previously, in the content process, all widgets were defined to be located at the screen origin. This also repairs mac e10s OOP plugin coordinate calculations that would be broken by this change.
