305405 - {inc}CSS styled HTML renders inconsistently when loaded from webserver vs local file

Status: RESOLVED FIXED

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

Description

[Benjamin Franz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6

When loading a self-contained XHTML page styled using inline CSS, the page
renders substantially differently depending on whether it was loaded from a
webserver or from a local file.



Reproducible: Always

Steps to Reproduce:
1. Create inline CSS styled HTML web page using multiple 'float: left;' block
styling sections and place on accessible webserver
2. Load locally in tab
3. Load remotely in tab
4. Compare views
Actual Results:  
Locally loaded version rendered as expected with blocks flowing depending on
browser window width. Remote page appeared to ignore 'float: left' styling and
rendered all styled blocks vertically. I was able to reproduce this behavior
both from Firefox 1.0.6 for Windows (Windows XP SP2) and from Firefox for Linux
1.0.6 (Fedora Core 3)

Expected Results:  
Expected identical renders.

I am using the default theme: Firefox (default) 2.0 Gerich and Horlander

Comment 1

[Benjamin Franz]

Attachment: Test case file that exhibits the behavior

This is the file I discovered the bug on. When loaded from a webserver it
renders differently than when loaded from a local file. I believe the local
behavior to be correct and the server loaded behavior to be incorrect.

Comment 2

[Benjamin Franz]

Attachment: Screenshot of local render

Screenshot of how the example HTML renders when loaded locally.

Comment 3

[Benjamin Franz]

Attachment: Screenshot of webserver loaded render

Screenshot of how the HTML test case renders when loaded from a webserver.

Comment 4

[Aaron Slunt]

WFM both cases Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050819 Firefox/1.0+ ID:2005081920

Reporter, please try using the latest branch build, and a clean profile.

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/

Comment 5

[Benjamin Franz]

(In reply to comment #4)
> WFM both cases Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
> Gecko/20050819 Firefox/1.0+ ID:2005081920
> 
> Reporter, please try using the latest branch build, and a clean profile.
> 
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/

I downloaded and installed the latest build for WinXP (after uninstalling the
1.0.6). The version reported is

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050821
Firefox/1.0+

I then created a new login account just to test with and loaded both local and
remote with it. I got exactly the same results I did before. 

The local copy renders correctly, the remote copy (loaded by clicking on the
'example' link on <URL:http://nihongo.org/snowhare/utilities/browsercounter/>)
does not render correctly. A right-click save of the target page to my local
drive renders correctly when opened via 'Open File'.

I'm attaching two more screenshots.

Comment 6

[Benjamin Franz]

Attachment: Deerpark WinXP 20050821 screenshot of local render

Screenshot of local render under 20050821 build on WinXP

Comment 7

[Benjamin Franz]

Attachment: Deerpark WinXP 20050821 screenshot of remote webserver render

Screenshot of render using 20050821 build on WinXP from remote webserver

Comment 8

[Aaron Slunt]

This is quite interesting.

Your testcase WFM both clicking on the attachment link and viewing it locally,
and sending a direct request for the page to that site also WFM, only by
clicking on the example link do I get inconsistent page rendering.

I'm not sure what's going on here yet, but I'll look the markup and css further
once I have more time.

I'll confirm this for now, only under the condition that it occurs by clicking
on the example link.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819
Firefox/1.0+ ID:2005081920

Comment 9

[Boris Zbarsky [:bzbarsky]]

The example link worksforme too, in a current trunk build...  Benjamin, are you still seeing this in Gecko 1.9a nightly builds?

Comment 10

[Benjamin Franz]

(In reply to comment #9)
> The example link worksforme too, in a current trunk build...  Benjamin, are you
> still seeing this in Gecko 1.9a nightly builds?
> 

For whatever reason, the copy on my own webserver no longer appears to show the behavior - but the (identical !!!) attached one on the bugzilla report does (using the nightly for 1.6a1 that I downloaded and installed a couple of minutes ago). 

Click on the 'Test case file that exhibits the behavior' attachment on the bugzilla report to see it mis-render the layout.

Comment 11

[Boris Zbarsky [:bzbarsky]]

I did click on it -- it didn't show the problem.

Martijn, want to try creating a reproducible testcase here?

Comment 12

[Martijn Wargers (dead)]

Attachment: testcase2

This testcase uses the js hack to trigger the bug.

Comment 13

[Martijn Wargers (dead)]

I think I made a testcase just like this one for a similar bug, but I haven't been able to find the bug yet.

Comment 14

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo]

Seems fixed by reflow branch landing

Comment 15

[Steve England [:stevee]]

Weirdness observed with:
-  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
(Square black borders are vertically stacked)

No weirdness observed with:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)
(Square black borders are horizontally aligned)

-->RESOLVED FIXED 

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Adding in-testsuite? nomination per bz's request in m.d.t.l. Sorry for the bugspam.