Random local page loading issues in Web+

[kallisti5]

As of the latest r1beta4 release candidate (rc0 , hrev56578+58), still seeing webpositive having issues loading local documents.

I have a physical desktop which only showed the gray bar at the top (even after multiple reloads), and a qemu vm which is failing to load css for the quickstart page (screenshot attached)

The "Stop" icon is still lit, even though the status bar says "finished"

[kallisti5]

Error:

Did not parse stylesheet at 'file:///boot/system/documentation/welcome/Haiku-doc.css' because non CSS MIME types are not allowed in strict mode.

[kallisti5]

Something of note....

src/data/mime_db/text/x-source-code has a META:SNUFF_RULE for or /* on the first line to identify "Source Code".

The css documents start with or /*

[humdinger]

I suppose I saw the same issue on the freshly installed r1beta4 RC, though I didn't check Terminal output: When trying to view the locally installed Userguide or QuickTour, the pages aren't rendered with their CSS. The remote versions on the Haiku website do work.

[pulkomandy]

haikuwebkit really needs the files to have the proper MIME types. But that didn't change since previous versions.

Did the files change? Did the MIME sniffing rules change? Did we forget to run mimeset on these css files?

[humdinger]

The Userguide and Welcome/QuickTour now come from recipes of haikuports. That it?

[pulkomandy]

That could explain it, yes. Files in packages should be mimeset at build time by haikuporter but I'm not sure how that works exactly, and what's in the builders MIME database (and if it's isloated between builds or global).

[kallisti5]

I'm not sure how that works exactly, and what's in the builders MIME database (and if it's isloated between builds or global).

​https://github.com/haikuports/haikuporter/blob/master/HaikuPorter/Package.py#L244

Looks something like:

mimeset --all --mimedb data/mime_db --mimedb ...haiku/data/mime_db .

The fact though that it's getting detected as "Source Code" probably means the weights changed. Extension should likely be valued over detection rules? (though I could see someone thinking detection rules should be valued over extension)

[kallisti5]

No real relevant changes I see:

• ​https://cgit.haiku-os.org/haiku/log/src/bin/mimeset.cpp
• ​https://cgit.haiku-os.org/haiku/log/src/kits/storage/mime

Unless one of the PVS fixes "fixed" something that was preventing the sniffing rules from working.

[pulkomandy]

More specific rules (like css) should have higher scores that generic rules (like sourcecode).

Not at my Haiku machine currently, I'll chech what we have as a sniffing rule for css and why these files aren't matched.

[pulkomandy]

Well actually, the css sniffing rule is... entirely missing: ​https://cgit.haiku-os.org/haiku/tree/src/data/mime_db/text/css

So that explains it. The MIME type for these files need to be set manually, or a sniffing rule added. Not sure how that was done before, but now it isn't done.

[bipolar]

Not sure how that was done before, but now it isn't done.

Maybe this explains the change?

From ​https://cgit.haiku-os.org/haiku/commit/src/data/mime_db/text/css?id=74f28747a23711ca0800e47f4bc892a1f0a98cde:

• text/x-source-code had its sniffing rules increased in priority, so that it would get precedence over text/plain and its own sniffing rules.

Edit: albeit that change is from a year and a half ago... so... maybe not.

[waddlesplash]

Added a workaround for the Welcome & Userguide packages in ​https://github.com/haikuports/haikuports/commit/f01281cf88797eabb586782f77411f29b31cb676

[humdinger]

I updated my RC installation and the local CSS issue is fixed.

[madmax]

Replying to pulkomandy:

haikuwebkit really needs the files to have the proper MIME types. But that didn't change since previous versions.

Just changed in 1.9.2. The path gets to mimeTypeForPath without the file protocol, so it skipped the attributes and got the type from the extension.

[humdinger]

Added a workaround for the Welcome & Userguide packages in ​​https://github.com/haikuports/haikuports/commit/f01281cf88797eabb586782f77411f29b31cb676

@waddlesplash: The BeBook package needs the same treatment.

[pulkomandy]

Can't we just add a sniffing rule for CSS instead of manually setting MIME types? Sound like a better idea to me?

I'll try to write one...

[humdinger]

Of course, a fix would be best. A generic CSS sniffer rule is beyond me though... Just wanted to make sure the important BeBook is readable when Beta4 hits, which I had the feeling might be any day now.

[pulkomandy]

Proposed rule: ​https://review.haiku-os.org/c/haiku/+/5948

We can start from here and refine it if we see problems with it.

[humdinger]

Did a quick test with a few css files, and it seems to work fine.

Problem is, however, you can't sniff out incorrectly set MIME types of files in packages. Therefore, even if we add the sniffer rule to the mime db, do all packages with html+css docs need to be re-packaged after the buildbots are updated?

[pulkomandy]

yes, or if there are no plans for buildbot updates we'll have to fix it "manually" for the packages that need it for beta4. and hopefully the problem is gone for beta5 or whatever the next release ends up being.

[humdinger]

What's currently happening if there is no sniffer rule? Couldn't we have it fall back to identifying the MIME type according to the file suffix?

[pulkomandy]

Currently they match the "sourcecode" rule, so that wouldn't help, we are not in the "there is no sniff rule" case.

Also I think I am not ready to give up on sniffing rules without at least attempting to put a bit more effort on it, and we could hrobably find or design a more automated and reliable way to identify files by their contents so we never have to resort to file extensions.

It will never be perfect (because someone can always come up with a file that is valid in at least two formats), but I think we can get it at "good enough" levels.

[humdinger]

Currently they match the "sourcecode" rule, so that wouldn't help, we are not in the "there is no sniff rule" case.

Of course. Erroneous thinking on my part. :facepalm:

Maybe a special keyword like "suffix" as sniffer rule could trigger a fallback. Of course if the sniffing itself could be improved, that would be best.

[pulkomandy]

Fox extensions-based sniffing, see #10067.

[waddlesplash]

Sniff rule added in hrev56664.