Bug 222867 – [Flatpak SDK] Direct AVIF loading does not work.

• Component: Images
• Status: RESOLVED FIXED

[ChangSeok Oh]

SSIA.

[ChangSeok Oh]

I investigated this issue in depth, and found that the root cause was flatpak sdk did not support avif mime type.

In webkit-side, we get a content type via g_file_info_get_content_type(info); in NetworkDataTaskSoup::didGetFileInfo. The returned type is 'application/octet-stream'. Why the glib returns the unknown content type is that xdg of flatpak sdk is not new enough to support avif. Please see https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/95

Actually I found two freedesktop.org.xml in my local webkit repo:
./WebKitBuild/UserFlatpak/runtime/org.webkit.Platform/x86_64/0.3/37c82c52d147824756b7cd2562549ad8cfcbc1ddf93e2aba33614a2325a70a07/files/share/mime/packages/freedesktop.org.xml
./WebKitBuild/UserFlatpak/runtime/org.webkit.Sdk/x86_64/0.3/e55e0606d22aee5dd1faeea8f35633363cae3e7a028efc0694631dc73b3d30b9/files/share/mime/packages/freedesktop.org.xml

None of them define the avif mime-type. Thus, updating xdg of flatpak SDK would fix this issue. @philipn, thought?

[Philippe Normand]

Sure, updating shared-mime-info to version 2.1 in the SDK fixes this bug :) And introduces thousands of layout test failures.

So somebody will need to bisect the regression in shared-mime-info. 1.10 good, 2.1 bad.

[Philippe Normand]

Created attachment 422531 [details]
Patch

[ChangSeok Oh]

(In reply to Philippe Normand from comment #2)
> Sure, updating shared-mime-info to version 2.1 in the SDK fixes this bug :)
> And introduces thousands of layout test failures.
> 
> So somebody will need to bisect the regression in shared-mime-info. 1.10
> good, 2.1 bad.

Can we do that in local without bumping up the SDK on server? I mean, can I just update only my local SDK for bisecting?

[Philippe Normand]

Yes, local SDK builds are possible:

webkit-flatpak-sdk --build all

Then install flatpak image locally:

webkit-flatpak --repo=$PWD/Tools/buildstream/repo -u

Then set this env var when running build-webkit/etc:

WEBKIT_FLATPAK_USER_DIR=$PWD/WebKitBuild/UserFlatpak.Local


The issue though is that this regression is quite old, see also bug 202321... gio detects this file LayoutTests/fast/xsl/extra-lf-at-end.html as xhtml for instance when the shared-mime-info db was built with shared-mime-info 2.1, whereas with a db built with 1.10, text/html is detected.

I'm not sure what to do... it's not the first time we have issues with shared-mime-info... I wonder if we should use that only as last resort and use the MIMETypeRegistry as first option.

[Philippe Normand]

Created attachment 427002 [details]
Patch

[Michael Catanzaro]

(In reply to Philippe Normand from comment #5)
> I'm not sure what to do... it's not the first time we have issues with
> shared-mime-info... I wonder if we should use that only as last resort and
> use the MIMETypeRegistry as first option.

I don't know, maybe. Our MIME type detection seems to be generally quite fragile and incompatible with what other browsers are doing....

[Michael Catanzaro]

Comment on attachment 427002 [details]
Patch

Please get Carlos Garcia's opinion before landing, but I think it makes sense. We have too many problems with misdetected MIME types and I wouldn't be surprised if this fixes other bugs too.

We might even consider removing extractMIMETypeFromMediaType altogether if that's what would best match the behavior of other browsers.

[Jon Bauman]

(In reply to Michael Catanzaro from comment #8)
> We might even consider removing extractMIMETypeFromMediaType altogether if
> that's what would best match the behavior of other browsers.

Regarding Firefox, https://bugzilla.mozilla.org/show_bug.cgi?id=1656099 may be of interest

[Michael Catanzaro]

(In reply to Jon Bauman from comment #9)
> Regarding Firefox, https://bugzilla.mozilla.org/show_bug.cgi?id=1656099 may
> be of interest

Interestingly, that looks like the opposite of what we're doing here, as this patch causes the file content to no longer be used.

[Carlos Garcia Campos]

Comment on attachment 427002 [details]
Patch

LGTM

[Philippe Normand]

(In reply to Michael Catanzaro from comment #10)
> (In reply to Jon Bauman from comment #9)
> > Regarding Firefox, https://bugzilla.mozilla.org/show_bug.cgi?id=1656099 may
> > be of interest
> 
> Interestingly, that looks like the opposite of what we're doing here, as
> this patch causes the file content to no longer be used.

For local files yes.
For remote assets the contents is still sniffed, afaik.

[EWS]

Committed r276635 (237063@main): <https://commits.webkit.org/237063@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 427002 [details].

[Radar WebKit Bug Importer]

<rdar://problem/77204106>