433482 - {inc} Floated Navigation in a special CSS setup is broken

Status: NEW

(Core :: Layout: Floats, defect)

Description

[Ben Scholzen]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

When visting the website, the navigation part is broken, which means, it is positioned below the actual navigation bar. This happens randomly, so it is not a basic CSS problem.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
1. Opening the website
2. Reloading or trying again later until the bug occurs
Actual Results:  
Navigation is positioned below navigation bar.

Expected Results:  
Navigation is positioned within the navigation bar.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 2

[Ben Scholzen]

I was just informed, that you can easily reproduce this bug.

When reloading from cache (F5), the bug doesn't occur, but when reloading from the server directly (CTRL + F5), the bug occurs.

Comment 3

[Ben Scholzen]

Still no update after about a year?

Comment 4

[Steven Bakhtiari]

I had a play with the CSS of the original site first brought this "bug" to the attention of Ben. The problem he describes is specifically caused by CSS generated content, using the :before pseudo class selector.

For example:

ul#navigation:before { content: url(path/to/image.png); }

This type of declaration was causing the list items to drop below the actualy bounds of the ul#navigation element.

A simple fix to "get around" this issue, is to specifically set the height of the generated content. In the case in question, I specified the height of the image that was being included.

With that said, during the course of my testing, I found that attempting to position CSS generated content was near enough impossible. For example, applying absolute positioning and changing the top and left properties had absolutely no effect, however the latest stable build of Opera moved the content, as expected. I was also unable to float the content. I'm not sure if the standards even dictate how user agents are supposed to treat the user generated content (it isn't added to the DOM, from what I can see - and isn't supposed to be), so would this be a bug?

I've just written a small test-case to highlight this lack of control over generated content - I'll add the test case and a screenshot to highlight the differences between firefox and the other browsers I tested (Webkit and Opera).

Comment 5

[Steven Bakhtiari]

Attachment: HTML test case

Comment 6

[Steven Bakhtiari]

Attachment: Screenshot of HTML test case

Screenshot of the HTML test case displayed in 3 browsers, first Firefox 3.0.10, then Arora (recent WebKit) and finally Opera 9.64. As you can see, Firefox 3 is the odd one out. Is it wrong? I don't know. Is it unexpected? Yes indeedy!

Comment 7

[philippe (part-time)]

(In reply to comment #4)

positioning/floating of generated content (::before/::after) is bug 238072, and is fixed on Gecko 1.9.1 - Firefox 3.5b4.

Comment 8

[Adrian Florinescu [:aflorinescu]]

It seems that this bug has been fixed for a while, closing it down as WFM on:
48.0a1 20160309030419Mozilla/5.0 (X11; Linux i686; rv:48.0) Gecko/20100101 Firefox/48.0

Comment 9

[Ben Scholzen]

Adrian, I just tested my original use-case, and the bug still occurs as described (by hitting ctrl+F5).

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(Reproducable quite easily with attachment 320723 [details] in a build from yesterday or today.  I don't see a problem with attachment 377961 [details], though.)

Comment 11

[Adrian Florinescu [:aflorinescu]]

My apologies, for some reason I couldn't initially get Mats testcase (attachment 320723 [details]). 
@David: Correct, I can reproduce it with :mats testcase, but not with original one (attachment 377961 [details]).