Closed Bug 500673 Opened 15 years ago Closed 14 years ago

<a> incorrectly treated as residual style

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: george.decherney, Unassigned)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [fixed by the HTML5 parser])

Attachments

(1 obsolete file) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11

Each block is supposed to represent one post and show a preview of that post. Randomly blocks are repeated and the repeated blocks show no preview. It is random which blocks are repeated and how many times they are repeated is also random. for example, if [1] is a post the page may output something like this [1][2][3][3][3][3][4][5][5][6][7][7][7][7][7][8] opposed to [1][2][3][4][5][6][7][8].

Reproducible: Sometimes

Steps to Reproduce:
1. load the page
2.
3.
Actual Results:  
same problem but may be a different order. happens not just on this specific archives page but all archives pages of Tumblr.

Expected Results:  
displayed one block per post with a preview within he block

I used Davidslog as an example because this is Tumblr reporting the problem. If you have any further questions feel free to contact us at support@tumblr.com, just mention you are responding to the bug ticket submitted by George D. It can occur on all archive pages. We have recoded much of the site in an attempt to fix the problem but due to a lack of a resolution we believe it might be a firefox issue. Thank you in advance.
Confirmed on Windows Vista, latest trunk. Regression range is: 
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1177105080&maxdate=1177110119 which points to Bug 84582.
Don't know if it is related to Bug 496631.
Blocks: 84582
Component: General → Style System (CSS)
Keywords: regression
Product: Firefox → Core
QA Contact: general → style-system
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm.  In this case it looks like the parser is screwing up somehow (maybe due to precisely when the sink gets flushed out or something?).  For a preview block that works, the DOM looks like this:

  <a class="brick">
    <div class="inside_brick">Some text</div>
    <div class="user_hover">Date</div>
  </a>

For a case that's broken, the DOM ends up looking like this:

  <a class="brick"> </a>
  <div class="inside_brick">
    <a class="brick">Some text</a>
  </div>
  <a class="brick"> </a>
  <div class="user_hover">
    <a class="brick">Date</a>
  </div>
  <a class="brick"> </a>

So you get those extra empty boxes.  I'm a little confused as to why that would happen for more than one "brick", though.

Reporter, does adding "<script> </script>" right after the <link> in your <head> make the problem go away?
Ria, do you think you can get a somewhat standalone testcase attached to this bug before the serverside changes here?
Component: Style System (CSS) → HTML: Parser
QA Contact: style-system → parser
Summary: Gecko handles output incorrectly → <a> incorrectly treated as residual style
Attached file A suspicious example (obsolete) — 
Be sure you save the file with CR+LF newlines.
The latter contains the 65535th and 65536th bytes in the file.
The two identical codes give different renderings with Firefox 3.5 RC 3 (safe mode, fresh profile).
If you enable Firebug, you can see that the DOM trees are different in the two cases.
(In reply to comment #4)
> Created an attachment (id=385511) [details]
> A suspicious example

After I uploaded this file, I found that the behavior described in Comment 4 occurs only when Attachment 385511 [details] is opened locally.  Is Comment 4 a separate bug?
That is almost certainly bug 324875... In fact, isn't this bug a dupe of that one as well?
Comment on attachment 385511 [details]
A suspicious example

(In reply to comment #6)
> That is almost certainly bug 324875... In fact, isn't this bug a dupe of that
> one as well?

Thanks for the information.
I agree that Comment 4 is a dupe of Bug 324875.
I am not sure about the original report.
Attachment #385511 - Attachment is obsolete: true
Sorry for the delay. I am working with the development team to test the solution offered in comment 2.
Blake, what confuses me is why the stylesheet would make a difference...
Oh, I missed that part... I'm not really sure... It could realistically depend on us not returning to the event loop anymore and thus picking up packets at different times.
Oh, I see.  Yeah, I bet with the stylesheet there we ended up blocking the parser for the sheet load, and buffering up all that text, then restarting the parser after the sheet was done loading... but since we had all the text, there were no packet boundary issues.

George, no worries.  Let me know whether what I suggested works at least as a workaround!
Sorry its taking me forever to respond and test we just got swamped in the office for a random reason but thank you all for your assistance. I promise I have not forgotten about it.
Hey Guys,

Sorry for the delay! we tried the solution offered in comment # 2 and it appears to be working. seems like a rather odd fix though. any insight on why that worked?
Oh, that just made sure to block the parser at that point until the stylesheet loaded (since the script execution waits for the stylesheet and the parser waits for the script to run on the off chance that it'll do a document.write()).  So it basically restored the Firefox 2 behavior (in Firefox 2 stylesheet loads always blocked the parser).
We now have an HTML parser that isn't confused by packet boundaries.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: