This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionEnd changes.
3) Changes the IDL type of HTMLInputElement's selectionEnd attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: J3Gkhr8VnbS
This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionStart changes.
3) Changes the IDL type of HTMLInputElement's selectionStart attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: JM9XXMMPUHM
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
Since we are now using cached selection state a lot more (instead of
initializing the editor whenever someone asks for selection state), we need to
actually update it more correctly when .value is set.
And since we now update the cached selection state for the case when .value has
been set (to point to the end of the text), we need to change
HTMLInputElement::HasCachedSelection to return false for that case. Otherwise
we will always do eager editor init on value set. We handle that by not doing
eager init if the cached selection is collapsed.
The web platform test changes test the "update on .value set" behavior. They
fail without this patch, pass with it.
MozReview-Commit-ID: DDU8U4MGb23
Both `goBack` and `goForward` commands should not return immediately,
but when the requested page has been fully loaded. To handle that a general
`waitForPageUnloaded` method has been added, which will call
`pollForReadyState` when necessary.
Similar to `get` the dispatcher cannot be used due to possible remoteness
changes. As such the driver has to poll the framescript until the page load
has been finished.
MozReview-Commit-ID: 4F7Piymxwhs
--HG--
extra : rebase_source : 58084cb9fa8ac96ced4ff5d719dd55cbb0dafa03
All navigation commands including get, goBack, goForward, and maybe others
in the future should rely on the same method for fetching the readyState of
a document. As such prepare `pollForReadyState` and `get` for the upcoming
usage.
MozReview-Commit-ID: 5Y4U9dgM7uj
--HG--
extra : rebase_source : f66908fbe013fd961468679862db4caa77230ec9
This simplifies the 'process_output' formatting in both the mach and tbpl formatters. It will also
add the string 'pid' somewhere in the format, but only if the process id is actually a positive int.
MozReview-Commit-ID: 6nc5q06cDfM
--HG--
extra : rebase_source : 67a435b653eed3cd374037f4bd30e1f65bf5615a
Currently the StructuredOutputParser validates all unstructured output against a series of error lists (regexes). However,
before this happens, the mochitest harness is converting all unstructured output to structured 'process_output' messages.
This means that Gecko output is not being checked against the error regexes.
This change ensure that in addition to unstructured output, we also validate 'process_output' messages against the error
lists.
MozReview-Commit-ID: DG6sZqpg5aw
--HG--
extra : rebase_source : 8d57c20cfb5690c6b10e0fccad56ad678647e5a8
Mochitest currently converts unstructured logs (e.g output from gecko) to 'info' messages. But
this means those messages won't be validated against mozharness' error logs. This change first
gets unstructured messages logged as process_output, and also ensures the StructuredOutputParser
in mozharness checks process_output messages against the error list.
MozReview-Commit-ID: KPTQnulwzyK
--HG--
extra : rebase_source : 52f2f048aee5bd40cde29030e7668b321366e9ec
I've moved the mozilla specific gtest stuff to link directly in xul-gtest
rather than in the gtest static library to make it possible for standalone
programs to link against this library and not have to link
against other mozilla libraries. This allows us to build
media/webrtc/signaling/fuzztest against this version of gtest rather than the
webrtc version of gtest, which I plan to remove in a follow on bug.
I had to add a global disable for -Wgnu-zero-variadic-macro-arguments as we
hit that everywhere we use the INSTANTIATE_TEST_CASE_P macro.
This brings forward the fix from Bug 844630 to the visibility of environ in
gtest-death-test.cc.
I also removed code that set GTEST_API_ to a visibility that conflicts with
what we've defined elsewhere in tree.
MozReview-Commit-ID: 3cfuapC6vn0
--HG--
extra : rebase_source : 6e5d2684718b6ddaa5a64c1f26a0172c91b5a719
This simplifies the 'process_output' formatting in both the mach and tbpl formatters. It will also
add the string 'pid' somewhere in the format, but only if the process id is actually a positive int.
MozReview-Commit-ID: 6nc5q06cDfM
--HG--
extra : rebase_source : 2c9ef125c19c06942a0c39d783151e8aa486a92c
Currently the StructuredOutputParser validates all unstructured output against a series of error lists (regexes). However,
before this happens, the mochitest harness is converting all unstructured output to structured 'process_output' messages.
This means that Gecko output is not being checked against the error regexes.
This change ensure that in addition to unstructured output, we also validate 'process_output' messages against the error
lists.
MozReview-Commit-ID: DG6sZqpg5aw
--HG--
extra : rebase_source : d07522ff9de09af5506d224885f452dae6ab8144
Mochitest currently converts unstructured logs (e.g output from gecko) to 'info' messages. But
this means those messages won't be validated against mozharness' error logs. This change first
gets unstructured messages logged as process_output, and also ensures the StructuredOutputParser
in mozharness checks process_output messages against the error list.
MozReview-Commit-ID: KPTQnulwzyK
--HG--
extra : rebase_source : bdcdbf5567355f28ab88d17b27f44d5dfa0467c2