HTML tag problem with story submission

[HelenL]

I've never seen that. Just now I went to https://www.literotica.com/s/honeys-rizz-quest?page=2, clicked on page 1, and the separators were missing; opened the source (Ctrl+U), searched for "* ", and they were there as expected.

A (client-side JS) script cannot modify the initial HTTP response, only the rendered DOM (HTML elements) of the page as displayed in the browser.

I managed to see the bug again in the page I've been working with (it's way more random than I thought) and tried what I'd done before, ^U copy etc., and the separators were present this time. But now I think that's a red herring because ^U is causing a page reload.

If instead I save the page locally and look at the HTML the separators are missing again in the code.

I'm convinced that this is a server-side problem, but I think our testing is heisenberging our results...

 

[MrPixel]

I think our testing is heisenberging our results...

Uh huh. Red herrings abound.

 

[TheLobster]

If instead I save the page locally and look at the HTML the separators are missing again in the code.

This looks like a difference between browser behavior. If I do the same in Chrome -- save the page where separators are missing -- I do get the same result as if I right-clicked, picked View Source and copy-pasted the HTML into a file. Your browser might be dumping the DOM instead.

But now I think that's a red herring because ^U is causing a page reload.

You're right that viewing the source makes a new request to fetch the page from scratch, but I've never seen such newly fetched (i.e., server-side rendered) page contain story content w/o the separators.

By the way, it is very easy to tell whether you're looking at server-side or client-side rendered story content. The server-side render will have the data-hk attributes everywhere, on pretty much every single <p> element; whereas a client-side render will have very few.

 

[IWroteThis]

I've never seen that. Just now I went to https://www.literotica.com/s/honeys-rizz-quest?page=2, clicked on page 1, and the separators were missing; opened the source (Ctrl+U), searched for "* ", and they were there as expected.

A (client-side JS) script cannot modify the initial HTTP response, only the rendered DOM (HTML elements) of the page as displayed in the browser.

View source pulls a new copy of the HTML, so it works like refreshing the page. To view the actual code of the buggy page, you have to use the debugging tools to see it live.

I tested this by comparing the code from View Source to the code shown by the debugger on both original/buggy and refreshed versions of the page. View Source matched the refreshed version, not the original buggy one.

 

[FrancesScott]

Does anyone have any suggestions for either fixing this issue, or changing our HTML to obviate it?

 

[old_prof]

Does anyone have any suggestions for either fixing this issue, or changing our HTML to obviate it?

Manu hires an underling who’s competent?

 

[FrancesScott]

Manu hires an underling who’s competent?

Maybe a sound idea, but any tips on how we might be able to force a fix through our own code?

 

[old_prof]

Maybe a sound idea, but any tips on how we might be able to force a fix through our own code?

Sorry. I know my suggestion was not helpful. I tried one idea and that didn’t work. I’ve got nothing

 

[HelenL]

Maybe a sound idea, but any tips on how we might be able to force a fix through our own code?

This is what I'm trying to get to, using your observation that centered headings are working.

Page 5 of Reborn has scene breaks and centered headings (^F to Another Wednesday). Each heading should have a centered ~~~~~ before it. It may or may not, but the heading always shows.

The submitted source for the this section is
...</p>
<p align="center">~~~~~</p>
<div align="center"><b><u>Another Wednesday</u></b></div><p>Kathryn...
where the red part may or may not appear, but the green always does. The differences I see are
1. uses <div> rather than <p>
2. is bold and underlined
3, has real text rather than just tildes
4. doesn't end with a newline
5. contents vary

1 is easy to substitute, but someone mentioned a few pages back that <p> and <div> both have the same issue, so not promising.
2 is probably a non-starter, since you won't want scene breaks to be bold and underlined
3 I'm still concerned that the code may be interpreting a sequence of non-text characters differently from readable text, so maybe a string of readable or partially readable text would work for a scene break (I'm trying I===I===I in my update)
4 Would be really weird for the parser to care about newlines
5 I have this notion that's even farther out than 3 that maybe there's some confusion with identical text groups causing them to get dropped, which doesn't affect sub-headings since they're always different. Since you don't want every scene break to be different this isn't really addressible.

Something is allowing sub-headings to escape the munching, so I've resubmitted my latest story with scene breaks as
<div align="center">|===|===|</div>[text continues here with no newline]
which incorporates changes for 1, 3, 4. Of course I won't know if it works for 45 days or so for the edit to post.

 

[old_prof]

This is what I'm trying to get to, using your observation that centered headings are working.

Page 5 of Reborn has scene breaks and centered headings (^F to Another Wednesday). Each heading should have a centered ~~~~~ before it. It may or may not, but the heading always shows.

The submitted source for the this section is
...</p>
<p align="center">~~~~~</p>
<div align="center"><b><u>Another Wednesday</u></b></div><p>Kathryn...
where the red part may or may not appear, but the green always does. The differences I see are
1. uses <div> rather than <p>
2. is bold and underlined
3, has real text rather than just tildes
4. doesn't end with a newline
5. contents vary

1 is easy to substitute, but someone mentioned a few pages back that <p> and <div> both have the same issue, so not promising.
2 is probably a non-starter, since you won't want scene breaks to be bold and underlined
3 I'm still concerned that the code may be interpreting a sequence of non-text characters differently from readable text, so maybe a string of readable or partially readable text would work for a scene break (I'm trying I===I===I in my update)
4 Would be really weird for the parser to care about newlines
5 I have this notion that's even farther out than 3 that maybe there's some confusion with identical text groups causing them to get dropped, which doesn't affect sub-headings since they're always different. Since you don't want every scene break to be different this isn't really addressible.

Something is allowing sub-headings to escape the munching, so I've resubmitted my latest story with scene breaks as
<div align="center">|===|===|</div>[text continues here with no newline]
which incorporates changes for 1, 3, 4. Of course I won't know if it works for 45 days or so for the edit to post.

I had noticed 3 and so tried posting one with text rather than punctuation. I think I tried all of o o o o, oooo, x x x x, and xxxxx. None of them worked any better then my standard +++++

 

[pink_silk_glove]

1 is easy to substitute, but someone mentioned a few pages back that <p> and <div> both have the same issue, so not promising.
2 is probably a non-starter, since you won't want scene breaks to be bold and underlined
3 I'm still concerned that the code may be interpreting a sequence of non-text characters differently from readable text, so maybe a string of readable or partially readable text would work for a scene break (I'm trying I===I===I in my update)
4 Would be really weird for the parser to care about newlines
5 I have this notion that's even farther out than 3 that maybe there's some confusion with identical text groups causing them to get dropped, which doesn't affect sub-headings since they're always different. Since you don't want every scene break to be different this isn't really addressible.

Something is allowing sub-headings to escape the munching, so I've resubmitted my latest story with scene breaks as
<div align="center">|===|===|</div>[text continues here with no newline]
which incorporates changes for 1, 3, 4. Of course I won't know if it works for 45 days or so for the edit to post.

Here is some code from one of my stories published a couple of years ago that is now as buggy as anything else.

<hr/>
<i>cuatro</i>

I used scene breaks simply numbered (in Spanish). These completely vanish, including the italicized text number. Uno, dos and tres are all on page 1 so are fine, Cuatro (page 2) and cinco (page 3) are gone (unless the page is refreshed) and the final part seis (toward bottom of page 3)) is fine. The story is four pages.

 

[HelenL]

Here is some code from one of my stories published a couple of years ago that is now as buggy as anything else.

<hr/>
<i>cuatro</i>

I used scene breaks simply numbered (in Spanish). These completely vanish, including the italicized text number. Uno, dos and tres are all on page 1 so are fine, Cuatro (page 2) and cinco (page 3) are gone (unless the page is refreshed) and the final part seis (toward bottom of page 3)) is fine. The story is four pages.

I thought that it only affected recent submissions. I guess if it's affecting everything then eventually everything should be fixed.

If your breaks included text, that negates my 5.

Edit: never mind, I see now, it's the <hr> that vanishes rather than the heading. It almost seems like the bug is deliberately (but intelligently) hunting out any kind of scene break and nuking it.

 

[pink_silk_glove]

I thought that it only affected recent submissions. I guess if it's affecting everything then eventually everything should be fixed.

If your breaks included text, that negates my 5.

Edit: never mind, I see now, it's the <hr> that vanishes rather than the heading. It almost seems like the bug is deliberately (but intelligently) hunting out any kind of scene break and nuking it.

Yes the /hr is a problem, but also the italicized text right under it. I don't know if I put a blank line between them if the italics will show but in previews if I put a carriage return between them I would get a double space. That's why they're one right below the other.

 

[pink_silk_glove]

By the way, it is very easy to tell whether you're looking at server-side or client-side rendered story content. The server-side render will have the data-hk attributes everywhere, on pretty much every single <p> element; whereas a client-side render will have very few.

If it is a client side problem, would everyone still be getting the same bug effects (as we seem to be) despite all of us having different clients (systems/browsers/devices) ?

 

[TheLobster]

If it is a client side problem, would everyone still be getting the same bug effects (as we seem to be) despite all of us having different clients (systems/browsers/devices) ?

Yes. The last few decades had brought enough unification of the Web standards that you can expect the same behavior from any modern browser. Discrepancies still exist, of course, but they are rare, and this bug in particular I have personally seen on three different browsers and platforms.

 

[HelenL]

I know that this problem has been fixed, but the fix seems to work only on desktop. I see no change in behavior on phone or tablet. I think I've managed to work around it, though.

Someone mentioned early in this thread that centering using <p align="center" and <div align="center" are both broken, but if I use <div align="center" outside a paragraph the scene break isn't eaten and it is centered. The Lit HTML moves the div into the subsequent paragraph, so <p><div align="center"..... but that's legal and I doubt it has anything to do with the problem. I think my "fix" is bypassing the problem by not creating an extra <p>.

Sample: page 2 of new story at Waterlily, page 2. Scene break should be ~25 lines down. See @TheLobster's post below.

Source HTML is

<p>story text</p>
<div align="center">~~~~~</div><p>more story text</p>

 

[TheLobster]

Sample: page 2 of new story at Waterlily, page 2. Scene break should be ~25 lines down.

For anyone who wants to test this at home (or maybe on the go, given we're talking about a mobile-only bug apparently), this is the link you should use instead.

Then, scroll down and go to page 2 (click the number of the arrow), so that this second page loads using the potentially buggy client-side path. You should see at least two separators within the first dozen or so paragraphs, and a few more further down.

 

[pink_silk_glove]

I know that this problem has been fixed, but the fix seems to work only on desktop.

I'm on desktop and it's not fixed.

 

[MrPixel]

I know that this problem has been fixed, but the fix seems to work only on desktop.

It has NOT been fixed, but degraded to the point of not being predictable on any platform. I experience the bug (again) consistently now since the recent code deployment. Very frustrating.

 

[HelenL]

For anyone who wants to test this at home (or maybe on the go, given we're talking about a mobile-only bug apparently), this is the link you should use instead.

Then, scroll down and go to page 2 (click the number of the arrow), so that this second page loads using the potentially buggy client-side path. You should see at least two separators within the first dozen or so paragraphs, and a few more further down.

Oh, thanks. I'd forgotten you had to navigate to the page locally. (Behaves the same for me on mobile though.)

 

[HelenL]

It has NOT been fixed, but degraded to the point of not being predictable on any platform. I experience the bug (again) consistently now since the recent code deployment. Very frustrating.

I see. I've only used desktop browsers a couple of times after the fix was announced in the other thread, and haven't seen an issue, but since it's still very much a problem on mobile (and unpredictable, and as bad as before) I don't doubt it.

The HTML generated by the method I've used is visibly different, without the illegal paragraph nesting, so I am fairly confident it will work.

 

[TheLobster]

Oh, thanks. I'd forgotten you had to navigate to the page locally. (Behaves the same for me on mobile though.)

Tested it on Chrome on Android and it worked for me just now. The separators showed just fine on the second page.

 

[pink_silk_glove]

Tested it on Chrome on Android and it worked for me just now. The separators showed just fine on the second page.

Some of them do and some of them don't.

 

[IWroteThis]

I know that this problem has been fixed, but the fix seems to work only on desktop. I see no change in behavior on phone or tablet. I think I've managed to work around it, though.

Someone mentioned early in this thread that centering using <p align="center" and <div align="center" are both broken, but if I use <div align="center" outside a paragraph the scene break isn't eaten and it is centered. The Lit HTML moves the div into the subsequent paragraph, so <p><div align="center"..... but that's legal and I doubt it has anything to do with the problem. I think my "fix" is bypassing the problem by not creating an extra <p>.

Sample: page 2 of new story at Waterlily, page 2. Scene break should be ~25 lines down. See @TheLobster's post below.

Source HTML is

<p>story text</p>
<div align="center">~~~~~</div><p>more story text</p>

Just remember, the more complex your workaround, the more likely it will break in the future and you'll need to submit an edit.

 

[MrPixel]

Just worked for me in Vivaldi Mac (a Chrome branch) and didn't work in DuckDuckGo on MacOS. Tried a different machine, also MacOS. Broken on Vivaldi, Firefox, and DuckDuckGo.

Insane.