Also remove mozilla.widget.use-argb-visuals which is useless since we don't allow transparent
toplevel windows.
MozReview-Commit-ID: 2ep3daeLZTG
--HG--
extra : rebase_source : 9ca5f2d0ded6dec1827caf2cb87e81fcb9b11792
Add a new config attribute to GtkCompositorWidgetInitData to allow transfer
the shape option from nsWindow. Also when shape is requested don't use XRender
or Shm widgets - only X11Image is supported now.
MozReview-Commit-ID: ElxnGQpLOry
--HG--
extra : rebase_source : 03552fc4103f6b22c512c07fe37102701998ed94
Derived routines for shape bitmap mask form nsWindow.cpp,
at WindowSurfaceX11Image we compose a final RGBA image and then create
the shape mask from image alpha channel.
Also the implementation is slightly simplified as it's meant as a fallback only.
MozReview-Commit-ID: 6VtGcsVKlcv
--HG--
extra : rebase_source : e8b96d68082ae687e376bc89c79f88f9c34cdc15
We cancel the permission request in the AutoplayPermissionRequest destructor,
and if we get a genuine cancel from the doorhanger. The Request reports the
cancel to the AutoplayPermissionManager, but we reuse the same manager across
different requests. So if a second request for permission comes in, we create a
new AutoplayPermissionRequest and fire that off to the front end code, but the
first request could be destroyed after the second request is dispatched but
before the response for the second request has retuned. Thus and the cancel in
the first's destructor could be reported to the manager as the second's result.
We should clear the AutoplayPermissionRequest's reference to the Manager in
Approve() and Cancel() so that we can't mixup the responses like this.
MozReview-Commit-ID: 1qYJfLOaqST
--HG--
extra : rebase_source : 871889da5420aff83c50933863ee3dd3d496bc12
We don't need to hold the strong reference in DocumentTimeline::ToTimeStamp().
MozReview-Commit-ID: 85UQBoPTjfA
--HG--
extra : rebase_source : 43f957d5b6cb9a2ed0db7105b23c634b04d10bc2
Mochitest to ensure that that zero reflows occur while iterating table
calling innerText and setting `display:none`.
MozReview-Commit-ID: K5vrsj3ogWy
--HG--
extra : rebase_source : 61ceacc5133db6a558a4e8b80f72f18a7195d153
To check that changes in P1 still work when layout is required.
MozReview-Commit-ID: ArqwDQXQwnR
--HG--
extra : rebase_source : 28cec6a6805bbd3c993c91115c663b791e35a20d
Instead of unconditionally flushing layout, flush style and skip flush
layout unless any frame state bits on the element, or ancestors,
indicate that a flush is required.
MozReview-Commit-ID: 4zaB1eaE0fm
--HG--
extra : rebase_source : a02b014e127f8fc3e27afedb2012e09a7e8905b8
Including refactoring mDirtyRoots into nsIPresShell to avoid virtual call.
MozReview-Commit-ID: KxST8FMsZl9
--HG--
extra : rebase_source : 1be1a8065815bb1e67293c7839c6e9189fc693bc
For files that come from the objdir in install manifests (eg: '!buildid.h'),
the FasterMake backend runs 'make -C dirname filename' to build the file
with the RecursiveMake backend before the install manifest is processed.
This works fine for GENERATED_FILES that produce a single target, but if
the GENERATED_FILES invocation produces multiple targets, the FasterMake
backend will run the command multiple times. Eg:
GENERATED_FILES += [('output1', 'output2')]
...
make -C dirname output1
make -C dirname output2
These invocations may be run in parallel, and would produce both output1
and output2 twice.
Instead we can track the GeneratedFile objects as they are emitted, and
only add the first output as a dependency on the install manifest. The
RecursiveMake backend is then only invoked once for the whole group of
GENERATED_FILES.
MozReview-Commit-ID: 6mvkHow2V2i
--HG--
extra : rebase_source : c6cd50d972fe8764831544685a63921e0548e765
This restricts the active-item-detection code to wrap lists because
other wrapper items are not supported yet.
MozReview-Commit-ID: JuirkAId7Kk
--HG--
extra : rebase_source : 5dbb8af8504f301ca49273b4f6f434a91524860a
