231655 - No margin between <p> and <table>

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect)

Description

[Tim De Pauw]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040117 Firebird/0.8.0+ (scragz)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040117 Firebird/0.8.0+ (scragz)

Subsequent <p> and <table> are sometimes clung to eachother, while they
sometimes have a margin between them (correct behavior). The table is inserted
through a document.write() in a remote JavaScript.

I've also seen Firebird perform the actual document.write() in the next page I
open, so I'm guessing it's related to the load time of the JS.

I'll attach a screenshot and a test case.

Reproducible: Sometimes

Steps to Reproduce:
1. Insert a <p> and a <script> with src
2. View page




Kind of looks like bug 87277 but then again, it doesn't, because of the loading
time thing. I wasn't sure what to search for.

Comment 1

[Tim De Pauw]

Attachment: Screenshot illustrating the problem

Issue is demonstrated in "forum", in bottom left corner of main frame

Comment 2

[Tim De Pauw]

Attachment: Test case

JavaScript file is fetched from remote server

Comment 3

[Boris Zbarsky [:bzbarsky]]

This seems to workforme in a current build no matter what I do.  Tim De Pauw,
can you still reproduce this?

Comment 4

[Tim De Pauw]

Since it used to happen only sporadically, it's hard to tell if the issue got
fixed. I loaded the test case a couple of times, each time with proper results.
I guess you could mark wfm and if ever run into it again, I'll reopen, if that's
allright with you.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, sounds good.

Comment 6

[Tim De Pauw]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040810
Firefox/0.9.1+
It's doing it again. :-\ Screenshot coming up.

Comment 7

[Tim De Pauw]

Attachment: New screenshot

Comment 8

[Boris Zbarsky [:bzbarsky]]

Tim, what page did you load to get that screenshot, exactly?  The testcase in
this bug has different content from your screenshot...

Comment 9

[Tim De Pauw]

That's the demo URL http://www.gratiz.be/ (with non-default colors but the CSS
is the same apart from the colors). I haven't been able to reproduce with the
test case yet. I'll try updating the test case with CSS. Should I use inline CSS
or fetch the stylesheet from the original server?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> That's the demo URL http://www.gratiz.be/ 

When I load that page it looks nothing like your screenshot... (it shows a
frameset, etc).

> Should I use inline CSS or fetch the stylesheet from the original server?

If the problem is reproducible in a self-contained testcase, please have it be
self-contained (inline CSS or <style> element).

Comment 11

[Tim De Pauw]

(In reply to comment #10)
> When I load that page it looks nothing like your screenshot... (it shows a
> frameset, etc).

Sorry about that. It has code to enfore the frameset so I had to link to the
main URL and I'd forgotten I'd disabled the forum cell for guests; I put it (the
"forum" part) back at the bottom right of the main frame of
http://www.gratiz.be/ now. I'm seeing the issue at least often on every first
load of the page, and then when I reload, it's fine.

The screenshot still applies, just with a different background color.

> If the problem is reproducible in a self-contained testcase, please have it be
> self-contained (inline CSS or <style> element).

I haven't been successful in doing so up until now. Maybe later.

Comment 12

[Jason Barnabe (np)]

WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040925
Firefox/0.10

Comment 13

[Tim De Pauw]

Still happens occasionally on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b) Gecko/20050116 Firefox/1.0+ (bangbang023), possibly only on a slow
connection. Could it have something to do with the delay between the rendering
of the <p> and the insertion/rendering of the <table>?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yes.  If so, you can test by putting:

  <script>var foo = document.body.offsetWidth; </script>

in various places to force reflow at those points and see whether that makes
this issue 100% reproducible...

Comment 15

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 16

[José Jeria]

This bug is very confusing, the screenshot nor the testcase doesn't really tell
what is wrong. Could you please attach a minimzed testcase explaining what is
wrong and what you expect?

Or you could attach a screenshot pointing out in red to show what you consider
is wrong.

But before that, please re-retest with a newer build.

Comment 17

[Tim De Pauw]

I haven't experienced this behavior in a while, so I assume it was fixed. Resolving WFM.