ID:73133
 
Resolved
Fixed in 443
BYOND Version:441
Operating System:Windows XP Home
Web Browser:Firefox 3.0.11
Status: Resolved (443)

This issue has been resolved.
Descriptive Problem Summary:
Like the problem with it not properly formatting style information until the first non-space, if you close an unopened HTML tag, it will start doing the same thing.

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
mob
verb
test()
src << {"Start:
cake
cake</font> cake</font>
cake"}
// this would work if 442 didn't output a linebreak or whatever it does before the lines that begin with a space. it still works with the first one.


Expected Results:
It wouldn't break.

Actual Results:
It did.

[edit]
441:

Notice how the formatting in between the middle "cake"s is messed up, and at the beginning of the third line.

442:

The same thing, except the third line doesn't mess up I'm assuming because of the weird linebreak thing.
[/edit]

Does the problem occur:
Every time? Or how often? Yes.
In other games? Yes.
In other user accounts? Maybe.
On other computers? Possibly.

When does the problem NOT occur?
When you don't close an unopened tag.

Workarounds:
Don't close unopened tags.

Naturally you wouldn't do this, but I noticed the bug in a function I had created that attempts to automatically close font tags during a mix-up.

Still, it's a bug either way.
You didn't specify what you're seeing in the output vs. what's expected. That's absolutely critical for a parser bug.
Ok, added a picture of what I'm seeing in both 441 and 442 (it is broken in both).

What I'm seeing is that the formatting is wrong (it isn't applying the styles it should be applying, exactly like the last bug I posted like I mentioned above) at the start of the closing tag until the first non-space.

What I'm expecting is that it should be formatting the style stuff properly.
In 443 I don't get the line break, but I do see what you mean about the two spaces between the double "cake" showing up without the right formatting.

I can see the cause of why this is happening. The unexpected </font> tag is popping other tags off the parsed tag stack, including the fictitious body tag that applies the styles from the stylesheet. When an actual word is output, it's restoring the body tag at that point.

There is a design question inherent in how we want to approach this, so I'm not sure how or whether this particular issue will be resolved. In the meantime the obvious workaround is not to use spurious closing tags.