Notes:
* In CSSAlignUtils.h, I'm just adding a forward-decl for a type used there.
* RubyUtils.h needs to #include nsIFrame.h -- a forward-declare won't
suffice -- because it makes a nsIFrame method-call ("aFrame->GetType()").
* ScrollSnap.h uses the "Maybe" type and a unit defined in
nsIScrollableFrame.h; hence it needs both of those headers.
MozReview-Commit-ID: KuhJVh9RTjZ
--HG--
extra : rebase_source : 062c1abfe9a1efeb7e241f38302c140075d2ae88
These newly-included headers' types are all used directly in the affected files.
MozReview-Commit-ID: 5NEA1QhSJKN
--HG--
extra : rebase_source : 3a9244fcb2a074df1c929de800ddd6cbc1f730e8
(The only reason this isn't triggering a compile error is due to .cpp files'
"using namespace mozilla" getting haphazardly shared via unified builds.)
MozReview-Commit-ID: 1zhJueMWOav
--HG--
extra : rebase_source : d08f18573d823968f654491e61428aa70a4c217c
This adds 2 "using namespace mozilla" (to provide various types),
and 2 "using namespace mozilla::gfx" (to provide mozilla::gfx::DrawTarget).
MozReview-Commit-ID: 2bXbMlr4Dbn
--HG--
extra : rebase_source : 9884419f08529469f23e3fc306ce6e4c57640f0d
The class definition (in the header file) is already inside the namespace. But
the method implementations are not (until now), and they've only been compiling
successfully thanks to a "using namespace mozilla" that this file was picking
up from another .cpp file, via unified builds.
MozReview-Commit-ID: ImRBpAVA0en
--HG--
extra : rebase_source : 291e2777187ef9af17e17eecc5e48eb27dd111ec
When the user switches back to a tab which has the selection highlight on
the document, call UpdateCarets() to bring the carets back.
MozReview-Commit-ID: LxNoNRl4FHZ
--HG--
extra : rebase_source : f6fdc9b5c646b064bbe1e27456bbeaac063bd04c
If the size of mask is empty, we wil hit this assertion, which is wrong.
MozReview-Commit-ID: LgulkGPsjyH
--HG--
extra : rebase_source : fbf8fc05a0bfa16b28599726f8ee85d4468d5d86
The class ViewportFrame doesn't have ns-prefix, so it's better to drop the
ns-prefix in the file names to avoid confusion.
MozReview-Commit-ID: 8Jrmfzb3tVR
--HG--
rename : layout/generic/nsViewportFrame.cpp => layout/generic/ViewportFrame.cpp
rename : layout/generic/nsViewportFrame.h => layout/generic/ViewportFrame.h
extra : rebase_source : d2c6a80275d696a2886983a4bbb46821784c7fe6
Need to add #includes "nsPresContext.h" and "nsThreadUtils.h" in
PresShell.h, and "nsViewportInfo.h" in MobileViewportManager.h to compile.
MozReview-Commit-ID: F8bmOwllOiH
--HG--
extra : rebase_source : cacbb30d854c68ea720f849d03b649bbd3c5da03
The class PresShell doesn't have ns-prefix, so it's better to drop ns-prefix
in the file names to avoid confusion.
MozReview-Commit-ID: IljxsF5CVjh
--HG--
rename : layout/base/nsPresShell.cpp => layout/base/PresShell.cpp
rename : layout/base/nsPresShell.h => layout/base/PresShell.h
extra : rebase_source : e73a6873f360a7223d87bd22d9854fc9603c499f
This change will allow the border drawing code to deal with the following
changes, which will make us no longer force the fieldset to be wider than the
legend. Without this patch, allowing the fieldset to be narrower than the
legend causes the vertical inline-start-side and inline-end-side borders of the
fieldset to paint under the legend, because the current code only modifies the
painting of the block-start-side border (the one the legend is positioned on).
This does change behavior in one situation, which the new tests test. For
relatively positioned legends, we used to use the original vertical location but
the positioned horizontal location of the legend to decide which parts of the
border to not paint. In the new setup, we use the original location for both.
I did check that this new behavior matches Chrome and Safari. Edge seems to
have our old behavior.
The only call site of CalcLengthWith() with a null style context is
CalcLengthWithInitialFont(). CalcLengthWithInitialFont() calls
CalcLengthWith() with a valid nsStyleFont and aUseProvidedRootEmSize
true, so we can get the rem unit font size from the nsStyleFont when called
from CalcLengthWithInitialFont().
MozReview-Commit-ID: A9LKfQEozaB
This is the first patch which creates a helper function to compute a line-width
value to an absolute length. With this helper, we could share the computation
for other line-width value properties, e.g., border-width, column-rule-width.
MozReview-Commit-ID: GnsmzGl5KBo
--HG--
extra : rebase_source : efe7c253b07c7d15531106f841383bd8a5ad463a