When the user clicks on a text node, the event handler sets the cursor
position to the location that was clicked. But it would then be set back
to 0 in the DOM node's focus handler. Leave the cursor alone, unless the
the DOM node was never set as the cursor position node (which will occur
when the user clicks on the DOM node, but outside the shadow text node).
In that case, move the cursor to the end of the text node.
The end result here is that the cursor is placed where the user clicked,
or set to the end of node if the user clicked outside of the shadow text
node.
You can now build with STYLE_INVALIDATION_DEBUG and get a debug stream
of reasons why style invalidations are happening and where.
I've rewritten this code many times, so instead of throwing it away once
again, I figured we should at least have it behind a flag.
Otherwise, it looks a bit awkward where the cursor position does not
update while the selection is elsewhere.
Note that this requires passing along the raw selection positions from
`set the selection range` to the elements. Otherwise, consider what will
happen if we set the selection start and end to the same value. By going
through the API accessor, we hit the case where the start and end are
the same value, and return the document cursor position. This would mean
the cursor position would not be updated.
The test changes here more closely match what Firefox produces now. It
is not a 100% match; the `select event fired` test case isn't right. The
problem is the event fires for the input element, but we most recently
focused the textarea element. Thus, when we retrieve the selection from
the input element, we return the document's cursor position, which is
actually in the textarea element. The fix will ultimately be to fully
implement the following:
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-textarea/input-cursor
That is, each input / textarea element should separately track its own
text cursor position.
For both types of elements, `.selectionStart`, `.selectionEnd`,
`.selectionDirection`, `.setSelectionRange()`, `.select()` and the
`select` event are now implemented.
Navigables are re-used for navigations within the same tab. Its current
ownership of the cursor position is a bit ad-hoc, so nothing in the spec
indicates when to reset the cursor, nor do we manually do so. So when a
cursor update happens on one page, that cursor is retained on the next
page.
Instead, let's have the document own the cursor. Each navigation results
in a new document, thus we don't need to worry about resetting cursors.
This also makes many of the callsites feel nicer. We were previously
often going from the node, to the document, to the navigable, to the
cursor. This patch removes the navigable hop.
The style of input and textarea elements is now invalidated when focus
is changed to a new element. This ensures any `:focus` selectors are
applied correctly.
And let the old shadow_root(), which was only supposed to be used by
bindings, be called shadow_root_for_bindings() instead.
This makes it much easier to read DOM code, and we don't have to worry
about when to use shadow_root_internal() or why.
This was resulting in a whole lot of rebuilding whenever a new IDL
interface was added.
Instead, just directly include the prototype in every C++ file which
needs it. While we only really need a forward declaration in each cpp
file; including the full prototype header (which itself only includes
LibJS/Object.h, which is already transitively brought in by
PlatformObject) - it seems like a small price to pay compared to what
feels like a full rebuild of LibWeb whenever a new IDL file is added.
Given all of these includes are only needed for the ::initialize
method, there is probably a smart way of avoiding this problem
altogether. I've considered both using some macro trickery or generating
these functions somehow instead.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
The API value of a <textarea> element is its raw value with normalized
newlines. This should be used in a couple of places where we currently
use the raw value.
These are invoked by GitHub when submitting a comment. Stub them out for
now, as this is enough to let GitHub proceed with (attempting) to submit
the comment.
We currently create a shadow tree once for each DOM element that renders
with a shadow tree (e.g. <input>, <details>). If such an element is
removed from the DOM, we must remove its shadow tree. Otherwise, the
shadow tree will refer to the old document in perpetuity.
If the node is added back to a DOM, then recreate the shadow tree.
This required dealing with a *lot* of fallout, but it's all basically
just switching from DeprecatedFlyString to either FlyString or
Optional<FlyString> in a hundred places to accommodate the change.
If an element is created from JS, it might have its contents modified
before it is inserted into the document. In this case, we don't have a
shadow tree yet and so trying to set m_text_node's text content would
cause a null dereference. So let's not do that. :^)
That case also means that by the time we do create the shadow tree, we
have the text content already, so we can set it there.
Added a test to verify that we don't crash, and that the text content
appears in the textarea whether it was inserted by JS or by the HTML
parser.
Give it a shadow tree, similar to HTMLInputElement's, so that we can
actually edit its contents at a basic level. Add some CSS to use the
`rows` and `cols` attributes as the size if they are present.