Closed Bug 352937 Opened 18 years ago Closed 16 years ago

CSS display: table sometimes creates new row after changing content

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 121142

People

(Reporter: info, Unassigned)

References

(
URL
)

Details

Attachments

(5 files, 1 obsolete file)

testcase - generated by sample Java servlet (follows)
2.71 KB, text/html
Details
screenshot of Acid2 test from 3.0a2
21.87 KB, image/png
Details
testcase - JavaServlet which pauses betwwen sending line 140 and 141
5.17 KB, text/x-java
Details
simple testcase - HTML file
2.78 KB, text/html
Details
Acid2 testcase in standalone HTML file
14.12 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Using div-container with display:table and three div-container display:table-cell should always create three cols. One row element (start and end) should be generated by the browser. After changing the content, the third display:table-cell-container is displayed in a second row. That may be after five times ore many more, it's different.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
1. create a html page width one div, display:table, and three divs, display:table-cell, inside the first div and create a link (like <a href="?test">) to reload the page. Put some content inside the table-cell elements.
2. load the page width different content.
3. click the link more times.

Actual Results:  
I only had one page width two rows. In the example file, it happens more often.

Expected Results:  
It should always display one row.

The bug may have relationships with other content or CSS in the demo URI. The change of content is the microtime (PHP) inside the teaser class element.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
Workaround:
Create a new div container between display:table and display:table-cell with display:table-row.
It depends on fact if page is loaded "fast", or if there is pause during loading display:table styled element. When only part of display:table element is loaded when Firefox starts rendering of table, gecko renders table elements into one row. After next part of display:table element is received, it is rendered on second and next lines.

You can test it on following example page I've created:

http://www.jirsak.org/gecko/bug

- when this page is loaded "fast", all menu items are rendered in one line.

When you append parameter pause=true, there is 1 second delay between sending menu item no 5 and 6 - gecko break line between them:

http://www.jirsak.org/gecko/bug?pause=true

Workaround with including display:table-row doesn't works for me (Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7).

Testcase and Java servlet which can send "paused" page mentioned above follows.
testcase - web page generated by servlet, with optional delay between menu item no 5 and no 6
You can run this servlet in any Java Servlet 2.4 compatible servlet engine (for example Tomcat or Jetty). When invoked without parameters, it send page as fast as it can. When invoked with parameter "pause=true", it pauses 1 second after sending menu5 item and before sending menu6 item. You can test it on http://www.jirsak.org/gecko/bug or http://www.jirsak.org/gecko/bug?pause=true
Workaround: force to reflow display:table element. For example you can use following JavaScript on page load (assume getElementById("menu") is the element with display:table):

<body onload="document.getElementById('menu').style.display='block'; window.setTimeout(new Function('document.getElementById(\'menu\').style.display=\'table\''), 10)">


Still in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2) Gecko/20070206 GranParadiso/3.0a2

This bug causes GranParadiso/3.0a2 doesn't pass Acid2 test. See http://www.jirsak.org/gecko/bug?acid2=frame Source code of both left and right frame are absolutely the same. The problem is in timing – so you cannot test it on  file from disc. It must be tested from webserver. The difference is pause between sending following lines of source code:

<li class="first-part"></li>
… 1 second pause …
<li class="second-part"></li>
<li class="third-part"></li>

Relevant part of source-code on the server side (in Java) is:

InputStreamReader isr = new InputStreamReader(GeckoBug.class.getResourceAsStream("acid2.html"));
BufferedReader reader = new BufferedReader(isr);

for (int i = 0; i < 140; i++) {
	String line = reader.readLine();
	if (line == null) {
		break;
	}
	writer.println(line);
}
	if (request.getParameter("pause") != null) {
	writer.flush();
	try {
		Thread.sleep(1000);
	} catch (InterruptedException e) {
		throw new ServletException(e);
	}
}

while (true) {
	String line = reader.readLine();
	if (line == null) {
		break;
	}
	writer.println(line);
}
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: 1.8 Branch → Trunk
Interestingly, your ACID2 testcase failed as you described once for me, but I haven't been able to reproduce it again since.
(In reply to comment #7)
> Interestingly, your ACID2 testcase failed as you described once for me, but I
> haven't been able to reproduce it again since.
> 

May be you have pages somewhere in cache now. The problem occurs only when loading the page is paused in right place. This is what my testcase does. When Firefox obtains the page from disc or from some cache, it is loaded all together and problem doesn't occur. Try Shift and click on Reload button to force loading from original webserver (to bypass cache).

I found this bug due to lags of busy webserver, so it can appear randomly on pages using display:table or display:table-cell. My testcase brings regular lag into page serving only, so the bug can be tested and we cannot wait for random lags.
You can test it with Java Servlet Container (for example Jetty – http://jetty.mortbay.org ). Try following web.xml:

<pre>
&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt;
&lt;web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"&gt;
  &lt;display-name&gt;Test WebApp&lt;/display-name&gt;

  &lt;servlet&gt;
    &lt;servlet-name&gt;Gecko&lt;/servlet-name&gt;
    &lt;servlet-class&gt;org.jirsak.test.GeckoBug&lt;/servlet-class&gt;
  &lt;/servlet&gt;

  &lt;servlet-mapping&gt;
    &lt;servlet-name&gt;Gecko&lt;/servlet-name&gt;
    &lt;url-pattern&gt;/bug&lt;/url-pattern&gt;
  &lt;/servlet-mapping&gt;

&lt;/web-app&gt;
</pre>

Than

http://localhost:8080/context/bug shows simple testace without pause (correct display)

http://localhost:8080/context/bug?pause shows simple testace with pause (incorrect display)

http://localhost:8080/context/bug?acid2=frame shows Acid2 testacase with non-paused page in the left frame and paused page in the right frame

http://localhost:8080/context/bug?acid2=true&pause=false#top shows Acid2 testacase without pause (correct display)

http://localhost:8080/context/bug?acid2=true&pause=true#top shows Acid2 testcase with pause (incorrect display)

The method related with Acid2 testcase is
<pre>private void printAcid2(HttpServletRequest request, PrintWriter writer)</pre>
Attachment #241365 - Attachment is obsolete: true
(In reply to comment #10)
Oh, I'm sorry for badly formatted web.xml. Trying again:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
  <display-name>Test WebApp</display-name>
  
  <servlet>
    <servlet-name>Gecko</servlet-name>
    <servlet-class>org.jirsak.test.GeckoBug</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>Gecko</servlet-name>
    <url-pattern>/bug</url-pattern>
  </servlet-mapping>
  
</web-app>

Created self-contained ready to run testcase for testing on local computer. You need only Java Runtime Environment (JRE) version 5.0 or higher – see http://java.sun.com/javase/downloads/index.jsp

Than download testcase.jar from http://www.jirsak.org/gecko/testcase.jar and run

java -jar testcase.jar

or

java -Djetty.port=8081 testcase.jar

if you want to run web server on different port (default is 8080).

Then point browser to http://localhost:8080/ and you can test.
http://weblogs.mozillazine.org/hyatt/archives/2003_08.html#003963 describes a way you can create a testcase with the equivalent of a pause in a standalone HTML file.  A servlet is unnecessary (and a huge amount of overkill, and nobody will ever bother setting it up to test).
(In reply to comment #13)
Thanks! It works. I'll prepare new testcases.
Items Menu to Menu10 should be on one line. The <script> only pauses parsing for a moment – it is replacement for pausing on server side or due to network lag.
The script added into original Acid2 test does nothing - it only pauses parsing of document for a moment – it simulates delay on server side or network lag
Isn't this basically bug 148810?
Depends on: 148810
Still in 3.0a8 – see comparison at http://jirsak.org/gecko/bug?acid2=frame
Looks like an exact duplicate of bug 121142 based on the testcases.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: