Instead of checking nsIFrame::IsTextFrame() and then casting to nsTextFrame,
the new code just checks the writing mode of the frame. Less casts; less
chance of pointer errors.
MozReview-Commit-ID: LrtthZjwYq6
--HG--
extra : rebase_source : 487ed4de272f514fe1f495ed1c2ddb9c8574d0a2
For Automated submission to AMO we need unique language pack versions for every submitted build.
This will produce versions that are not valid for AMO on nightly (61.0a1buildid2018...) but that's ok, we're not ready to
submit these automatically on the nightly channel yet, they do still install fine into Firefox manually.
On beta/release/esr the version will however be ok for AMO "60.0buildid2018..." and will be reasonably unique per push.
This patch has the intent that, outside of automation, users who don't set a buildid get a langpack version without that
specified (rather than a buildid being automatically generated for them).
The releng scriptworker (addonscript) that will do the publishing to AMO will additionally sanity check that the string
'buildid' is present in the version part, so we don't accidentally break this functionality in production.
This patch is also intended to be uplifted to Gecko 60 to support ESR60 needs.
MozReview-Commit-ID: KuvwMyD6bwd
--HG--
extra : rebase_source : 04ecd87a15d5640f510b1f6123ba9467ccc4592a
This patch doesn't affect behavior; it just adjusts a variable for clarity.
Really, this variable tracks which axis (inline vs. block) is the main axis (if
we're a flex item). So, this patch morphs the variable to more directly track
that.
The variable's old name 'usingFlexBasisForISize' was confusing, because even
when it was set to 'true', we might not *really* be using the flex-basis in
place of the ISize property. In particular: when we have 'flex-basis:auto', we
don't use 'flex-basis' in place of the ISize/BSize property -- rather, that
indicates that 'flex-basis' is *deferring* to the main-axis size property.
Hopefully the new name/type makes it clearer what we're actually tracking.
MozReview-Commit-ID: ITkb4zuEwgQ
--HG--
extra : rebase_source : 99ebae4e7f6bb87c8001ca589db5e4f375344da3
This patch doesn't affect behavior - it's just refactoring / de-duplicating.
(The refactored function does include some new "legacy box" code, just for
completeness & to ensure that the included assertion passes. But beyond the
assertion, that new code isn't exercised right now -- this function's only
callsites are skipped if the NS_STATE_FLEX_IS_EMULATING_LEGACY_BOX state-bit is
set on the container. Hence, this patch still doesn't affect behavior, even
though it's adding some new logic in the refactored-out function.)
MozReview-Commit-ID: G5aCzwTwkTa
--HG--
extra : rebase_source : 695a2341074b1c344a1c5831989b95a693e16970
Currently, clicking the close button or otherwise trying to exit the Windows
stub installer always ends up canceling the installation. This patch prompts
the user to either continue or cancel the installation.
MozReview-Commit-ID: 4KMgCcyjTnv
--HG--
extra : rebase_source : 0c0636c9c02fabd32df37471033d8e847caea5d3
This fixes a bug which the main bug 986081 patch exposes because it tries to
cancel a download in InetBgDl and then show a dialog box immediately afterward.
Without this patch, doing that very early on in the request (meaning before any
redirect is fully handled) would result in a 10 second UI hang.
MozReview-Commit-ID: 1zBxZrllFC
--HG--
extra : rebase_source : 523b2b37035a7fc6f435acd1f7437fbbbcf2adc6
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
This is a simple bug of internal API of HTMLEditor. HTMLEditor::GetBlock()
tries to retrieve nearest ancestor block node (including itself) of a node.
HTMLEditor::GetBlock() may have ancestor limiter typically it's active
editing host to prevent to modify editing host or its ancestor accidentally.
However, it forgets to call HTMLEditor::GetBlockNodeParent() with the given
ancestor limit node. Therefore, if editing host is an inline element and
its parent is a block element, the editing host is split accidentally.
MozReview-Commit-ID: Ermmxdnk4KB
--HG--
extra : rebase_source : c9b57c5bb28cd63b6f16702317f7ddb7fb5a26f6
test_419731.js can be removed since it is already covered by browser_bookmarkProperties_editTagContainer.js
MozReview-Commit-ID: K0LFuTptWyW
--HG--
extra : rebase_source : 10066aa0bdb6a598fc6af638fed455d58422b7fb
There's no reason to ask GL since we should know the answers.
Also GL is tricky on how it handles these semi-deprecated queries.
Official GL stance is "don't ask questions you know the answer to".
MozReview-Commit-ID: F7p73eSTrYw
