Fix example text popup not updating correctly when scan resolution is set to word

[jamesmaa]

Fixes #1526

The html for the example text upon loading the settings page

<div class="example-text-container">
    <input type="text" class="example-text example-text-input" id="example-text-input" lang="en" hidden>
    <span class="example-text" id="example-text">rea</span>
</div>

In a normal operations, when a user clicks on the example text, the <span> becomes hidden and the <input> becomes visible. However, all search is done through the value set in the <span> class.

We have the class PopupPreviewFrame (plus an obscure css rule) that manages the state between the <input> and the <span> elements.

When search is triggered, Yomitan searches for value inside <span>. Since the span is hidden while editing the example text, the element would normally be skipped to scanning in DOMTextScanner. But since the initial node of the text source range IS the span text, the first node value in DOMTextScanner is processed no matter what

const textNode = this._exampleText.firstChild;
const range = document.createRange();
range.selectNodeContents(textNode);
const source = TextSourceRange.create(range);

In the case of the scanResolution set to word, upon initiating the scan, we try to expand the beginning of the initial range to encompass the entire word by looking backwards to find the word boundary. In the case of example text, we exit the <span> text to find a space to determine we've reached a word boundary. HOWEVER, this causes a search that starts outside the visibility: none <span> element to be skipped due to how DOMTextScanner skips hidden elements.

Why didn't this break in other UX flows?
In the case of a scanResolution = 'character', we don't try to change the initial range startOffset, so the initial starting node for the search is within the hidden <span>
In the case of a scanResolution = 'word' page load, the <input> value is hidden while <span> is visible, so moving the startOffset of the initial range doesn't affect the scanability of the span text.

Solutions considered

So in terms of fixes I had two potential options that I've explored. The first is to fix the behavior of the visibility of <input> and <span> to update correctly BEFORE the search begins since. This might be weird UX though since I'm not sure what would happen when you update the visibility of an input element while still in focus.

The second potential fix is to prevent the DOMTextScanner from leaving the <span> element. I tried implementing this earlier and it does complicate the DOMTextScanner a bit by forcing the scanner to peek at the contents of the previous DOM node before traversing it, which I feel like violates some abstraction boundaries of how DOMTextScanner is currently implemented.

Solution proposed

I figured the easiest solution is to just add an extra option disallowExpandStartOffset that is set to true only in the example text popup frame. This prevents the startOffset from leaving the initial hidden <span>, thereby allowing scan to successfully work. This fixes our problem "cleanly" without changing too much of how we manage the popup-preview or the DOMTextScanner