In bug 1331509, mRemoteFrame started getting populated earlier, while the DPI
and default scale values remained unpopulated until RecvShow was called. This
opened a small window where calling TabChild::GetDPI (and GetDefaultScale) would
result in a sync IPC message where previously it would just return -1. This
restores the original behaviour and elimintes the perf regression from the
sync IPC.
MozReview-Commit-ID: AikQmZjVHc9
--HG--
extra : rebase_source : f8c5245a4241c8cf7c2786407deb8c6ef71bb089
This patch fixes:
* some long lines
* some odd indent
* wrapping one line blocks with {}
* removing B2G specific block
in event handlers in TabChild, TabParent and PuppetWidget.
MozReview-Commit-ID: 6xMsNEDA5nv
--HG--
extra : rebase_source : 7f5ff8830842af9338085a31ac4b40d6c1fb91fe
In non-e10s, all tabs of a window would share one nsRootPresContext. When
switching tabs, the tab switch paint would trigger a call to
nsRootPresContext::ComputePluginGeometryUpdates, which would call
SetEmptyWidgetConfiguration on all registered nsPluginFrames, notably also
those inside the tab that was hidden.
With e10s, every tab has its own nsRootPresContext, and paints in one tab do
not trigger calls to nsRootPresContext::ComputePluginGeometryUpdates on the
root pres contexts of other tabs. So when painting the new tab, the registered
plugin frames in the old tab were not notified that they were now hidden.
This patch now does that in TabChild::MakeHidden.
MozReview-Commit-ID: LlW9dKKFqZE
--HG--
extra : rebase_source : 0e7f24d7ef90d8582d7f60729e712bca78ed8e17
In cases where a mouse click that starts a scrollbar drag is also what
layerizes the scroll frame, the StartAsyncScrollbarDrag message needs to
arrive after the layer transaction. This patch ensures it does.
MozReview-Commit-ID: A02qRb6yWxg
--HG--
extra : rebase_source : 3517e8c8a578a0bd257a80bb8cb81303d171bb6c
Every new PBrowser, whether it's created by the parent or the child, needs
to get a TabGroup assigned to it. That way IPC messages for the PBrowser will
be dispatched to that TabGroup.
For new PBrowsers created by the child, we just create a new TabGroup or reuse
the opener's TabGroup.
For PBrowsers created by the parent, the child needs to intercept the
PBrowserConstructor message and assign a TabGroup immediately. PBrowsers created
by the parent never have an opener so we can always create a new TabGroup.
In both cases, the nsGlobalWindow::TabGroupOuter logic needs to be updated to
read the TabGroup out of the IPC code. Otherwise the DOM and IPC code will get
out of sync about TabGroups.
MozReview-Commit-ID: D5iEdgirfvK
The class PresShell doesn't have ns-prefix, so it's better to drop ns-prefix
in the file names to avoid confusion.
MozReview-Commit-ID: IljxsF5CVjh
--HG--
rename : layout/base/nsPresShell.cpp => layout/base/PresShell.cpp
rename : layout/base/nsPresShell.h => layout/base/PresShell.h
extra : rebase_source : e73a6873f360a7223d87bd22d9854fc9603c499f
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
We now call NotifyAsyncPanZoomStarted/Stopped precisely on the document
which is being transformed, so we no longer need to notify the child
docshells which was added in Bug 1088559.
Remove the |nsIDocument| argument for ProcessAPZStateChange(), which is not
used anymore.
mActiveAPZTransforms added in bug 1142926 is removed because AccessibleCaret
is the only consumer for AsyncPanZoomStarted/Stopped, and it now defaults to
always show while scrolling, i.e.
"layout.accessiblecaret.always_show_when_scrolling" defaults to true. And I
cannot reproduce the bug even if I turn off the preference.
MozReview-Commit-ID: DiEk2gCIHn2