bug#22250: 25.0.50; Eww fails to break RTL paragraph

[Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>]

I see that you found something with that other file, that's good.  My
script-based test case contains no diacritics though, so it is still
another problem.  I have uploaded this now to my private webserver as
<https://odoacer.turtle-trading.net/abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-test.html>.
This URL reproduces the problem for me after "G RET".

Eli Zaretskii writes:
> (Why is receiving a page from a server different from visiting the
> same page as a disk file?  The way shr works, this should produce
> exactly the same results, no?)

It gets worse, I set a breakpoint in eww-render yesterday.  At that
point in the code I understand that everything just works from a
temporary buffer containing the HTTP headers and the HTML.  I got the
error not depending on the buffer contents (IOW with the *same* contents
in the temp buffer), but depending on the length of the URL.  I thought
that the message "Loading ..." that is shown in the eww buffer might
trigger the problem.  So today I disabled that and tried my test case,
and it worked.  But than I tried my actual pages and came upon the case
that I just sent in the other post, where it still did not work.

> Failing that, can you describe what exactly do you see, or maybe step
> through the code in Edebug and tell which part(s) misbehave?

So I set a breakpoint on shr-vertical-motion and ran my script test
case.  Remember that this works the first time through but fails when
reloaded with "G RET".

In the good case, for the first line, point is at position 1,
shr-vertical-motion calls vertical-motion with (78 . 0) as parameter and
afterwards, point is at 94.  Which is a good place to break.

In the bad case, for the first line, everything looks the same,
vertical-motion gets called with the same parameter, but when it returns
point is at 161.  Which is not good.

Delving into the C code:

In the good case, it->w->hscroll is 0, in the bad case it->w->hscroll is
68.  Experimentation tells me that the interpretation of window-hscroll
(whether it refers to the left or the right margin) depends on
bidi-paragraph-direction, is that right?

Anyway, when I set bidi-paragraph-direction to left-to-right manually
before I press "G RET" than the problem does not occur.

Note that at the point when vertical-motion is called and gives
different answers, bidi-paragraph-direction is always right-to-left, so
it looks like some window parameter that depends on
bidi-paragraph-direction is cached somewhere?