BTW: This is not linux specific, it also occurs on Windows 10 aswell.

This is interesting. What you're describing sounds like a possibly interesting bug, though I am unable to reproduce.

My reduction here http://jsbin.com/qoxiduf/edit?html,output always displays the name of the UA stylesheet font family both in Firefox and Chrome.

Could you help me creating a test case that does something different?

Hey, yes this is because your stylesheet contains only 1 line and has a very small file size because of that. 
This bug seems to occur when the stylesheet has a large file size. Try adding bootstrap v4 (https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/css/bootstrap.min.css) css to your stylesheet and try again. 

Thank you for providing more feedback. Adding requester "dglazkov@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It seems JSBin modifies the result because after downloading your test case and running it on my dev machine, it displays "Arial" in both firefox and chrome.
And after adding bootstrap v4 css I see "Times New Roman" in Chrome and "Arial" in Firefox which approves my initial test case from stackoverflow.

Please also see the network tabs which show that Firefox (https://i.stack.imgur.com/S6O5b.png) puts DOMContentLoaded after the stylesheet loads which Chrome (https://i.stack.imgur.com/uVNjh.png) doesn't.

What I also found out just now is that if you add an inline script tag below the stylesheet and move the deferred script tag up, then the deferred script tag waits until the stylesheet is loaded before executing.

<script src="main2.js" defer></script>
<link rel="stylesheet" href="main2.css">
<script>
    console.log('jdjd');
</script>

Can you explain this behaviour?

Yeah, this is enough for me to confirm. Changing state to untriaged.

Re comment 6. A script element in the document will always cause the parser to wait for all style sheets to load before executing the contents of that script element. This is what's called "style sheet blocking script": https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model:a-style-sheet-that-is-blocking-scripts

What you've found is an interesting case where the script element is deferred and thus is no longer blocked by the style sheet.

The question your test case is asking is whether the DOMContentLoaded event should be blocking on pending style sheets. My intuition is "no" (Chrome behavior), but it looks like Firefox is trying to say "yes" somehow.

At the very least, this is an interop bug: both Chrome and Firefox need to behave in the same way.

I don't think you can rely on all stylesheet being loaded at DOMContentLoaded.

One possible explanation is that firefox is triggering DOMContentLoaded after pending stylesheet since they correctly dispatch the event asynchronously per spec, while Blink dispatches it synchronously (which is a bug: crbug.com/425790 )

I think not blocking DCL on stylesheet is correct behavior, so marking this bug as WONTFIX. 

dglazkov@chromium.org confirmed this behaviour is not correct and that this is a bug. I find this very disappointing that this got marked as WONTFIX.

So you say firefox is doing everything completely fine per spec, Blink has some bug which you think is related to this one but then you say you think that the current behaviour of chrome is correct? 
I don't think this makes any sense or I just don't understand your answer correctly. Can you point that out in more detail?

Another use case would be that if a javascript function needs to read an elements width or height, the javascript function needs to wait for css to be parsed because elsewhere it would return wrong results. 

How should one to deal with that type of situation without waiting for window.load which really should be avoided because then the javascript function has to wait for all images to be loaded?