EditorBase::CreateTxnForComposition() just hides what it does. For its caller,
creating a factory method, CompositionTransaction::Create(), is clearer what
it does.
Additionally, capsuling the creation in CompositionTransaction class can make
the text node information in TextComposition updated automatically. So, now,
it might be better to update them in DoTransaction() because there is a lag
between creating the transaction and calling DoTransaction(). However, this
patch doesn't want to change any existing behavior. So, this doesn't fix this
issue.
MozReview-Commit-ID: K8ci7ytwh1u
--HG--
extra : rebase_source : d468a0fc997c99f78f7eb46451082e7f1e052890
EditorBase::CreateTxnForCreateElement() just hides what it does. Let's make
the caller what it does with creating CreateElementTransaction::Create().
MozReview-Commit-ID: DYcfQV6KiUZ
--HG--
extra : rebase_source : d3f31b8db92bd3b2af464c66e064dd7b21018960
EditorBase::CreateTxnForInsertNode() just hides what it does. Let's create
InsertNodeTransaction::Create() and make the caller clearer.
MozReview-Commit-ID: 2J2WV73cdsm
--HG--
extra : rebase_source : 15b6391aee5beca4401e7c7a4ee8bf350a7590fd
EditorBase::CreateTxnForInsertText() just hides what it exactly does.
Rewriting it with a static factory method, InsertTextTransaction::Create()
should be clearer for its caller.
MozReview-Commit-ID: Er7Zlhtbnb0
--HG--
extra : rebase_source : 9dc71b3baab839f61153b96806fac5baae5d46cb
This matches Blink's behavior.
Just skipping table row groups from being containing blocks makes
layout/reftests/table-overflow/table-cell-block-overflow.html render differently
(and way more different than any other browser, actually...), so I avoided doing
that.
Though I'm not really proud of this one, better ideas welcome. Maybe I should
just fix table layout so that we agree with WebKit / Blink... But that seemed
harder, too.
MozReview-Commit-ID: AkUB4MFzwZK
Note that we need to use the virtual-with-gpu instances on windows for
WebRender to even start up.
MozReview-Commit-ID: 6fMDun7casP
--HG--
extra : rebase_source : 5068bd17d11725c2c0f5bd0b387a54047475f0c6
The check should read index >= self.len(). But it doesn't matter anyway since
we're covered by Rust's bound checks by default anyway.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6524d2281453da816c532dc83a522331df8ce9c0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a5fd5040f80563badd67ac7e65b36511454fbe49
The only reason autospider builds succeed in running tests at the moment
is that there is a libnspr4 library installed at the system level on
Centos that is binary compatible with what the js shell requires.
While on the long run we should just avoid depending on libnspr4 at all,
in the short term, we should make the effort to make those tests use the
libnspr4 present in dist/bin.
For the tests executed from js/src/Makefile.in, it turns out there is
already a level of wrapping that does that, relying on run-mozilla.sh,
which is only installed on gecko builds. Installing it on standalone js
builds solve half the problem.
The other half is addressed by setting LD_LIBRARY_PATH before invoking
the js shell in the various places it's invoked.
--HG--
extra : rebase_source : 25f4b1f5c78eb84e48046dc83798f07eb02d4a81
