c-c nor add-ons seem noet to use it. We should remove this.
MozReview-Commit-ID: 3jN8kUp6D4Z
--HG--
extra : rebase_source : cc31001bb87da2888a9c1da6d92a305cdebebb7a
Resizer and etc attributes on table editor still use nsIDOMElement. Converting to Element makes both implementation and the callers simpler.
MozReview-Commit-ID: TTFSvqn5GE
--HG--
extra : rebase_source : 705576c4eb0fe5f8f566f3415a8a72842c919edd
Now we can return Element directly via CreateAnonymousElement. We should use it.
MozReview-Commit-ID: Et1i3hLVSqc
--HG--
extra : rebase_source : e09c2b2b41481dd6608d9c816676030d8aae1ed6
I would like to nsIAtom and mozilla::dom::Element version of CreateAnonymousElement to clean up code. When getting/setting attirubte, editor sometimes use string, not nsGkAtoms. We should use new mozilla::dom::Element methods.
Also, we should add _moz_anonclass to atom list that uses on editor.
MozReview-Commit-ID: ICaAWVPjcej
--HG--
extra : rebase_source : 9585214aa678c16905250265a75b817c90246fcc
We have no mochitest for objectResizing and inlineTableEditing. So I add simple test for this.
MozReview-Commit-ID: Hnjpopr3h5F
--HG--
extra : rebase_source : 8cb81a89f11d4092f2adaa8822733f861a71ace1
As noted on the bug, because we call getMigratorKeyForDefaultBrowser() multiple times,
its value no longer reflects the (deleted) registry key for subsequent calls.
While we can fix this for the automigrate case by just passing the default we determined a few
lines earlier (and that seems worth doing to avoid busywork), there are 2 small problems
with this:
1) if the default browser has no data, `migratorKey` won't be set, and so we'll call the same
method again anyway, and the message reported in the error console will be that we can't
migrate from Firefox, when the real problem is that we can't migrate from the original
default browser.
2) there are other callers besides AutoMigrate. Specifically, migration.js also calls this
method.
To deal with these, I've fixed getMigratorKeyForDefaultBrowser() to return the same
registry-based value for its lifetime if we hit the 'the default is firefox, go look for an
earlier default' case.
I've verified that either the s/aMigratorKey/migratorKey/ or the change to
getMigratorKeyForDefaultBrowser() are sufficient to make this work properly in the
automigration case.
While I was here, I also updated one of the error messages to be more explicit.
MozReview-Commit-ID: GeUNTfScMMB
--HG--
extra : rebase_source : 09b4b5fef85c4668bc0931de2c8cf3d1a32e2b42
The postfix operator++ was actually incorrectly implemented as a prefix
version. Since it's only used in NS_FOR_CSS_SIDES, let's changed it to
prefix version.
MozReview-Commit-ID: GbdB2ZC9KyW
--HG--
extra : rebase_source : a46deea148e07609ca32e6836738de7296090f95
Those bits are already defined as enum in gfx/2d/Types.h.
MozReview-Commit-ID: 8E81lW9WnAg
--HG--
extra : rebase_source : 959d723a7a223b08a4f0935f4cc4ff894cae1260
This patch was written with the help of the following script. Also, manually
add mozilla qualifier to the enum values in nsStyleCoord.h, gfxRect.h, and
Types.h to make it build.
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "NS_SIDE_TOP" "eSideTop"
rename "NS_SIDE_RIGHT" "eSideRight"
rename "NS_SIDE_BOTTOM" "eSideBottom"
rename "NS_SIDE_LEFT" "eSideLeft"
MozReview-Commit-ID: 9T0ORsqM6nP
--HG--
extra : rebase_source : 884ad96104c6e9cf6c8b3145d2d3a071ecccfe6a
This patch is written with the help of the following script.
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "css::Side" "Side"
MozReview-Commit-ID: DPV6vivpPUp
--HG--
extra : rebase_source : 9c4f66dc9d2b26c89a4517fba4ff9c5db413411b
Make them live with the definition of enum Side.
MozReview-Commit-ID: 5uJPxFPOj79
--HG--
extra : rebase_source : 566f1a680ae85b61b1af0f643f59a4d1ac7472d3
Originally, we use the follwoing statement to determine whether generate mask
for an SVG element:
aUsage.shouldGenerateMaskLayer =
maskFrames.Length() == 1 && maskFrames[0];
maskFrames[0] is not null only if that mask resource is an SVG-mask. That means
we will not generate mask for image mask to any SVG one.
MozReview-Commit-ID: 4QiifC6J0UR
--HG--
extra : rebase_source : aa90599fc4955c0eb6e5d9d10c168b8643c32e03
When the first time user clicks download panel popup to hide the drop marker popup, Windows fires WA_ACTIVATE with wParam includes WA_CLICKACTIVATE to the download panel. In that case the popupWindow is the drop marker. We shouldn't roll up popups by handling WA_ACTIVATE since we'll handle the rollup behavior with WM_LBUTTONDOWN message.
MozReview-Commit-ID: 43jCgdBjjUN
--HG--
extra : rebase_source : 371de468252e7716e2ffe30520939650f76a4222
In order to use single_value_to_css() in
Servo_DeclarationBlock_SerializeOneValue(), we need to pass the property name
and a flag for custom properties.
MozReview-Commit-ID: 5HfI2qOmPwP
--HG--
extra : rebase_source : 968468b3c9313c4ec3007ee9883075c8fc4ab769
Also call mResourceCallback->Disconnect() in the destructor in case Shutdown() is not called to avoid dangling pointer.
MozReview-Commit-ID: 1qV4m8nWlGq
--HG--
extra : rebase_source : f40f77d64ccaace921625067ff8c51e322eec1b9
We were seeing almost permaorange failures in the WebRTC H.264/GMP tests
due to the GMP being shutdown in the parent process in between the
content process performing an OOP select operation and then performing
an OOP launch operation.
That is, in GeckoMediaPluginServiceChild::GetContentParent() in between
the SendSelectGMP completing and the SendLaunchGMP completing, the GMP
would shutdown and so when the launch operation ran in the main process
it would fail.
The select and launch are seperate operations so that the crash handler
can be reported to the content process and an association can be made
in the content process between the plugin ID and the crash helper before
we try to launch the GMP. This is so that if the GMP crashes on startup,
we're ready to handle the crash.
However it turns out that if the GMP crashes on startup, the crash report
message comes in after another round of the event/IPC message loop. So we
actually do have time in the content process to connect the crash helper
after the launch fails.
So in order to fix the problem of the GMP shutting down in between select
and launch, we can partially revert the changes I made in Bug 1267918 to
merge selecting and launching GMPs back into a single operation.
MozReview-Commit-ID: 5n4T1Gqlvr3
--HG--
extra : rebase_source : 6e6892a5e32a485b5bfc2f93bddb2d2fe5a422bd
In a similar vein to the previous patch, while we're waiting on a
GetContentParent promise to resolve, we don't want the GMPParent
to shutdown. So make IsUsed() check whether we're waiting on a
GetContentParent promise to resolve, so we don't pull the rug out
from under any code waiting to get a content parent to bridge a
GMP.
MozReview-Commit-ID: 8cTCuXLXMsK
--HG--
extra : rebase_source : 8cc04d57ea1ef4e48c7ff088dbb12eabe4b3b223
extra : source : f79a51d9bd193024f7359ba6ff75076b15d15faf
When GMPService::GetContentParent returns a MozPromise, we end up failing in
test_peerConnection_scaleResolution.html with e10s enabled because we Close()
the GMPContentParent twice. The test causes two GMPVideoEncoderParents to
be created. When the number of IPDL actors on the GMPContentParent reach 0,
we close the IPC connection. With GetContentParent() returning a MozPromise,
it's more async, and so we can end up requesting the content parent in order
to create the second GMPVideoEncoderParent, but while we're waiting for
the promise to resolve the previous GMPVideoEncoderParent is destroyed and
the GMPContentParent closes its IPC connection. Then the GetContentParent
promise resolves, and that fails to operate correctly since it's closed its
IPC connection.
My solution here is to add a "blocker" that prevents the GMPContentParent from
being shutdown while we're waiting for the GetContentParent promise to resolve.
MozReview-Commit-ID: HxBkFkmv0tV
--HG--
extra : rebase_source : 59aa7bcfe8b8f44274d136d6147a946542a64fff
extra : source : 59ab10349b58b0fbe13dca9312ec82332f7c3dbe
On Fennec, we would use external app (Android view) to play the media whih is
unsupported by gecko. We implement some special logic in error sink.
(1) dispatch "OpenMediaWithExternalApp" event
we use this event to start the android video player
(2) doesn't dispatch "error" event
some JS players won't let user to trigger play() again after receving the "error".
So we don't dispatch that event if we want to play the unsupported media more than once.
MozReview-Commit-ID: 7fZK5hdvaOG
--HG--
extra : rebase_source : 929db331c22e31a74f76dfa89a99a8adac65d0f6
On fennec we have the special workaround that is doesn't dispatch the "error" event when the error is
"MEDIA_ERR_SRC_NOT_SUPPORTED" because we will use an external app to open it.
But we don't want this behavior affect the tests we already have, so close the pref.
MozReview-Commit-ID: 9aoy1vnekvY
--HG--
extra : rebase_source : 9ac045b7595eadd36039bc6f42b32e4d3eac421b
Error sink would be response for the error handling, we could write different
error dispatching stragedies for different situation. eg. if we can play
unsupported type media with external app, we won't dispatch the "error" event on fennec.
MozReview-Commit-ID: Lm4x9ksspAY
--HG--
extra : rebase_source : 05331714425ea111d21f06fc03abfc1b016654ca
This patch is just renames. No logic change for the function.
MozReview-Commit-ID: K7w0YL3G3gu
--HG--
extra : rebase_source : d72ecdcb4d4455f4950c8673c81fbfc7c1b4f54c
The tests cases are designed based on the integer solution to the ellipse
equation (x/a)^2 + (y/b)^2 = 1, where x=36, y=32, a=60, b=40.
MozReview-Commit-ID: De2fXcb6ypP
--HG--
extra : rebase_source : a64f490ff41c020b84025266c0c255d93a158eea
We need to consider the case when only one of the four corner radius is
specified. The two reftests are added to test 'border-top-right-radius' and
'border-bottom-right-radius', respectively.
MozReview-Commit-ID: De2fXcb6ypP
--HG--
extra : rebase_source : 51da04a7a7d60d580b46d9ac8ed4bfd7e9666766
According to the spec, 6.4. Abstract-to-Physical Mappings,
line-left/line-right are equal to inline-start/inline-end when the direction
is the same. So we should use IsBlockLTR() instead of IsLineInverted().
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: 7onE0SuHtdj
--HG--
extra : rebase_source : df0083ed7e28469a2343a8607840585e93502b80
Tobias Schneider
Tracy Walker
Hamel Joshi
Matthew Noorenberghe
Michael Ratcliffe
Makoto Kato
Gijs Kruitbosch
Sylvestre Ledru
Ting-Yu Lin
cku
Kilik Kuo
Daosheng Mu
Stone Shih
maliu
Boris Chiou
JW Wang
Chris Pearce
Xidorn Quan
Iris Hsiao
Henry Chang
Alastor Wu
peter chang
Astley Chen