WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 232471
232386
REGRESSION(
r284521
) [GTK][WPE] many tests report parse errors as a result of the test files being interpreted as XHTML rather than HTML
https://bugs.webkit.org/show_bug.cgi?id=232386
Summary
REGRESSION(r284521) [GTK][WPE] many tests report parse errors as a result of ...
Arcady Goldmints-Orlov
Reported
2021-10-27 09:59:47 PDT
As a result of the change in
r284521
, numerous test files have started getting loaded as XHTML rather than HTML and the results of those tests end up being just a parse error message.
Attachments
Add attachment
proposed patch, testcase, etc.
Michael Catanzaro
Comment 1
2021-10-27 10:09:56 PDT
Of course, since
r284521
was just a straight revert of
r276635
, I would expect the test expectations to go back to what they were prior to
r276635
. The *correct* behavior would be "match whatever Safari does," but I suspect we never did. My recommended solution, from
bug #230797
: """ Of course, it would be *better* for WebKit to make content type decisions based on the DOCTYPE instead, but we can't expect a content sniffer to do that. We would have to implement it ourselves in WebKit, rather than farming out the work to GIO. I wonder how other ports handle this. """ This is what Bastien has recommended, as well.
Michael Catanzaro
Comment 2
2021-10-27 10:12:46 PDT
(In reply to Michael Catanzaro from
comment #1
)
> Of course, since
r284521
was just a straight revert of
r276635
, I would > expect the test expectations to go back to what they were prior to
r276635
.
Maybe the shared-mime-info version upgrade is related? I didn't revert the shared-mime-info version upgrade. The addition of new parse errors could mean shared-mime-info is just doing a better job of detecting XHTML than it was before.
Arcady Goldmints-Orlov
Comment 3
2021-10-27 14:18:35 PDT
I gardened some of the failures in
r284936
, and I am going to take a look at what happens if I revert the shared-mime-info change as well.
Lauro Moura
Comment 4
2021-10-29 15:02:39 PDT
(In reply to Michael Catanzaro from
comment #2
)
> (In reply to Michael Catanzaro from
comment #1
) > > Of course, since
r284521
was just a straight revert of
r276635
, I would > > expect the test expectations to go back to what they were prior to
r276635
. > > Maybe the shared-mime-info version upgrade is related? I didn't revert the > shared-mime-info version upgrade. The addition of new parse errors could > mean shared-mime-info is just doing a better job of detecting XHTML than it > was before.
The shared-mime-info was bumped from 1.10 to 2.1 in
r276635
. Among other changes: 1.13: * Prefer text/html to XHTML for *.html files * Better magic for text/html files * Fix SVG magic for files embedded in HTML 1.15: * Fix some HTML files being detected as XML (from:
https://gitlab.freedesktop.org/xdg/shared-mime-info/-/releases
)
Michael Catanzaro
Comment 5
2021-11-10 06:14:45 PST
We currently have two different bugs for this issue. This one is older, but I think there's a little more useful discussion in the other bug, so let's keep that one instead. *** This bug has been marked as a duplicate of
bug 232471
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug