Some object has properties in the safeGetterValues property, like ArrayBuffer
for example.
We now evaluate this property too when building the Rep. A function was created
to retrieve the property value since in safeGetterValues, the value is a wrapper
object with a getterValue property holding the actual value.
We add some tests to make sure we handle those grips as expected.
MozReview-Commit-ID: JqnTXnnAZpd
--HG--
extra : rebase_source : f001a57ab8785dd12dde6afce24cd2c899d60f10
We want entering/exiting dormant to be transparent to the media element. So we don't
change next frame status when entering/exiting dormant.
MozReview-Commit-ID: DCWxAGZ9sVw
--HG--
extra : rebase_source : 80131199556ed7b3338155d96970193ff313ac1f
extra : intermediate-source : 8fe29ca11789d8e2b5aa57c578be1a65e7fefdf4
extra : source : 3aab523e17402eecb56edbb74b00201d924c6010
Display a longString with what is available on the grip.
Straight from the server, a longString grip has a "initial"
property, which contains the first 10000 chars of the string.
The grip can also contains a "fullText" property that should
be set when the user want to display the full text of the string.
For example, in the DOM Panel, it would be when the user click on
the expand arrow.
The fullText needs to be computed with the result of the
LongStringClient.substring function, but it's not the responsability
of the Reps to do such thing.
In rep-utils, we extract the logic that replace non-printable
characters in its own function and export it, so we can use it outside
the cropString function.
Add some test to make sure LongString are displayed as expected in the
several modes.
MozReview-Commit-ID: 3P9fPBixm2v
--HG--
extra : rebase_source : 87ed610cb6d2e142728f0df9d35f1dd7a4748d18
In nsBlockFrame::PlaceLine(), we query the float available space by
using the line's BSize(), which may cause the line to reflow again due
to available space shrunk.
The first issue lies in the second reflow. That is, we do not leverage
the line's BSize() computed in the first reflow to query the float
available space when updating the inline reflow engine in
BlockReflowInput::AddFloat(). So some tall inline elements could still
overlap the floats as in the first reflow.
To solve this, we cache current line's BSize so that it could be
used to update the inline reflow engine when redo the line.
Another issue is in nsBlockFrame::PlaceLine(). When determined whether
the available space is shrunk, we use the float manager's state *before*
placing the line. So if current line has floats, they're not considered.
To solve this, we use the current set of floats to get the float available
space for comparison, and leave the original aFloatAvailableSpace to provide
the information when redoing the line.
MozReview-Commit-ID: GqqNlphgxYS
--HG--
extra : rebase_source : e2c64ab1ac363c7a08e532dc043bee69d6455049
This patch is based on bug 1291110 comment 29, but |aCanGrow| is preserved,
since the set of float available spaces we'll be testing in Part 4 are
difference from the one we enforced here.
MozReview-Commit-ID: LswbIaRukVR
--HG--
extra : rebase_source : 007d55fd867d052163ea5bb4222baf201fe30bcf
Rename to make the variable name consistent with the writing-mode
terminology used in PlaceLine().
MozReview-Commit-ID: AvhwHyHz7hV
--HG--
extra : rebase_source : bcec67d9959c1b881b4d287dbbab47dd0d6e0de9
It would always return true, and there's already a MediaDecoder::IsWaveEnabled()
MozReview-Commit-ID: 6FXgMRMnVb9
--HG--
extra : rebase_source : a42582ce417d916ca92fb014e5998292f6585b87
In this test, we assume the caret does not appear at the end of the input.
However in this case, self.actions.flick() will select all text within the
input, and then send_keys() will replace it with '!'. As a result, the final
content might varies on different platforms. Test the final content match
tho target_content might not be reliable.
To fix this, we instead assert that final content does *not* match the
non_target_content as the bug occurs.
MozReview-Commit-ID: 2YRN8W3PUXG
--HG--
extra : rebase_source : c63b631c609992fccf350d3088bba8e0621d9a55
The current state of python configure sandbox execution is that if a
template imports a module, and a function defined in the template tries
to use the module, it doesn't work. Ideally, it would, but rather than
try to fix this corner case, we remove the unit tests that assume it
works (and consequently pass for half bad reasons), and add a unit test
so that the behavior doesn't change unwillingly.
--HG--
extra : rebase_source : 579ba2bc7c19d4fe7df11bbdb1ceb6171a1ee857
Making this constructor non-explicit will permit automatic conversions from
'nullptr' into RefPtr types, which I think are not dangerous.
The one spot that this affects is in 'UserDataType nsBaseHashtable::Get(KeyType)',
which does a 'return 0;' into the UserDataType, which could be a bool, an int, a
RefPtr or other. I'm changing that into a C++11 "value initialization", which
falls back to "zero initialization" for PODs: 'return UserDataType{};'.
Also fixed the comment to clarify not-found return values, as Get(KeyType) was
not only used for pointers anyway.
MozReview-Commit-ID: F41VlvTNOZU
--HG--
extra : rebase_source : 71d5dacac75ca188e5c55d45f48a5fca76d953c6
Giving '0' (literal zero) to RefPtr is now ambiguous, as both
RefPtr(decltype(nullptr)) and RefPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: A458A4e9for
--HG--
extra : rebase_source : bc4107ce1767329e3dddfe34c55ba79202192e06
Added constructor and operator= from a nullptr, bypassing the incoming pointer
check.
Note that the constructor is 'explicit', because one particular use in
nsBaseHashtable is doing a 'return 0' into a templated type that is a RefPtr in
many cases. Making this new constructor explicit removes it from consideration
in this case.
As it's not strictly necessary to have it MOZ_IMPLICIT (but could still be
nice), I will tackle that in the patch after next.
Also changed all zeroes into nullptr when relevant in RefPtr.h (other system-
wide affected files will be updated in following patch.)
MozReview-Commit-ID: Ds4CEv9hZWI
--HG--
extra : rebase_source : f4ec156b13ea3bdcf32b1a33d76ff9771ad6d1dc
