`HTMLEditRules::WillMakeBasicBlock()` just calls
`HTMLEditor::FormatBlockContainer()` and it's called only for
`EditSubAction::eCreateOrRemoveBlock` and it's used only in
`HTMLEditor::InsertBasicBlockWithTransaction()`. Therefore, we can replace
calling `HTMLEditRules::WillDoAction()` in it with what
`HTMLEditRules::WIllMakeBasicBlock()` does.
First, `HTMLEditRules::WillDoAction()` checks whether first selection range
is editable. If it's not so, it returns `NS_OK` with setting `aCancel` to
`true`. Therefore, this patch moves this part to
`HTMLEditor::CanHandleHTMLEditSubAction()` for making
`HTMLEditor::InsertBasicBlockWithTransaction()` can check it easier.
Next, `HTMLEditor::InsertBasicBlockWithTransaction()` does something if
`HTMLEditRules::WillDoAction()` returns as not handled nor canceled.
However, this special handling requires at least one selection range:
https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/editor/libeditor/HTMLEditor.cpp#2284-2288
Surprisingly, `handled` is set to `false` only when there is an error or
there is no selection range. Therefore, this long block has already been
dead code so that we can remove this. Removing this block causes that we
become not throwing exception when `Document.execCommand("formatblock")`
without selection ranges. But this is better since Chrome does not throw
excption.
Finally, this patch renames some related methods:
- `HTMLEditor::FormatBlockContainer()` -> `HTMLEditor::FormatBlockContainerWithTransaction()`
- `HTMLEditor::InsertBasicBlockWithTransaction()` -> `HTMLEditor::FormatBlockContainerAsSubAction()`
Differential Revision: https://phabricator.services.mozilla.com/D44179
--HG--
extra : moz-landing-system : lando
And this fixes the caller which has not guaranteed the lifetime of the
start container.
Differential Revision: https://phabricator.services.mozilla.com/D44175
--HG--
extra : moz-landing-system : lando
The mach driver will now run all misspelled commands with Python 3. That means
we can't automatically execute the suggested command anymore, as it may need to
run against Python 2.
Ideally we could figure out a way to check the command against the 'mach'
whitelist, but until then, let's just disable automatic execution. Worst case
scenario we can turn it back on after the migration has finished.
Differential Revision: https://phabricator.services.mozilla.com/D44282
--HG--
extra : moz-landing-system : lando
So that we can restrict QI(nsIIdentChannel) to nsIHttpChannel and DocumentChannelChild objects only.
Differential Revision: https://phabricator.services.mozilla.com/D44111
MANUAL PUSH: multiple authors stack
DocumentChannel acts as a replacement for HttpChannel where redirects are now entirely handled in the DocumentChannelParent. The ContentChild will receive the final nsIChannel once all redirects have been handled.
Differential Revision: https://phabricator.services.mozilla.com/D37490
We can deduct it from the nsIChannel argument already. In the future, the httpParent may be either HttpChannelParent or DocumentChannelParent.
Differential Revision: https://phabricator.services.mozilla.com/D40971
The devtools listens to http-on-opening-request event which is expected to receive a nsIHttpChannel. However future changes will make it that it's not always a nsIHttpChannel that can fire such event.
As such we create an intermediary interface nsIIdentChannel and move the subset generating such event in nsIHttpChannel there.
Differential Revision: https://phabricator.services.mozilla.com/D40968
This more closely follow the code as earlier documented. To remove all ambiguities, the idl documentation was amended.
Differential Revision: https://phabricator.services.mozilla.com/D40961
This class allows to encapsulate all the information required in order to create a new HttpChannel object following a redirect.
Differential Revision: https://phabricator.services.mozilla.com/D40959
This method & the chunkCountLimit_ variable are unnecessary. The maximum
permitted nursery size is tracked in the GCSchedulingTunables class.
Differential Revision: https://phabricator.services.mozilla.com/D39285
--HG--
extra : moz-landing-system : lando
The new variable, 'newMinNurseryBytes' is more in-line with the other
'newMaxNurseryBytes'.
Differential Revision: https://phabricator.services.mozilla.com/D39284
--HG--
extra : moz-landing-system : lando
We used to calculate the nursery's maximum size in chunks, and track the
maximum number of chunks permitted. This could lead to some unexpected
behaviour with a larger nursery than requested. Calculating it in bytes is
simpler, avoids this problem, and is more in-line with other calculations.
Differential Revision: https://phabricator.services.mozilla.com/D39281
--HG--
extra : moz-landing-system : lando
The Nursery almost always exists. To remove the nursery's chunkCountLimit_
field we need to remove Nursery::exists(), so no-longer use it in the JIT.
Differential Revision: https://phabricator.services.mozilla.com/D39280
--HG--
extra : moz-landing-system : lando
