[Webkit-unassigned] [Bug 235444] [GTK][STABLE] More missing headers and preprocessor guards for non-unified 2.34.4 build

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=235444

--- Comment #8 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Dennis from comment #6)
> So webkit-gtk users shouldn't be able to disable "accessibility"? And why
> would I need a "fullscreen api" - maybe I'm not understanding what it means,
> but I never intend to use my browser in fullscreen mode. And why would I
> ever need "resource load statistics" - I'm pretty sure I've never used them
> in the past several years?

Normally we only expose build options when there is a new build dependency that might not be available on older systems. You can simply not use the feature at runtime if you don't want it. WebKitGTK always has accessibility support enabled. I don't know much about fullscreen, but I imagine disabling that option would likely break the fullscreen button on every video player, for instance. Not sure why other ports would ever use it.

Then resource load statistics is intelligent tracking prevention. That flag has been renamed in trunk, which is why your patch failed EWS again. You failed to read my first comment in this issue. I don't think your patch is going to be accepted if you're unable to respond to my feedback. We don't accept patches onto the stable branch unless a corresponding patch has landed in master first. Fixing 2.34 only to see you come back with similar patches for 2.36 a few months later, because you didn't land your changes into trunk first, is a waste of everybody's time, which is why it's not allowed here. (This best practice applies to all software projects, not just WebKit.)

(In reply to Dennis from comment #7)
> Also, are you saying that those preprocessor guards work properly in other
> (non-unified) WebKit ports?

They would be expected to work in at least one other port. (Sometimes this is not always true. :)

> That I'm the only one bumping into those bugs with my gtk port?

You're trying to use options that are not meant to be used with WebKitGTK, and discovering that they do not build, as expected. How did you even find these options? We have them marked as ADVANCED to ensure CMake doesn't expose them unless you purposefully go looking for the hidden options.

The non-ADVANCED options are public and expected to work. If you change them and then wind up with build failures, that's a bug to be fixed.

I don't mind adding #includes where useful. Nobody is going to complain about that. But in the GTK-specific files, you should only use guards if the GTK port actually allows changing the value of those guards (i.e. it is not marked ADVANCED).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220123/3bc1efc3/attachment-0001.htm>