EventPath is disabled in Chromium builds causing incompatibility issues in many sites

[Asesh Shrestha]

Hi, recently we across an issue where zooming in/out on a canvas using mouse scroll button and dragging using the same button would not work at all in Chromium builds but works in Chrome. 

 We have modified our Chromium fork to use --force-fieldtrials to tackle issues which are seen in Chromium builds but not in Chrome. While debugging our Chromium fork, I noticed that renderer processes are launched with --disable-features=EventPath but its enabled for Chrome. So I modified our fork not to do so. Now its working as expected, fortunately.

Is there any reason to do so? This will increase compatibility issues in Chromium builds.

Thanks

[K. Moon]

See crbug.com/1277431.

”This email and any files transmitted with it may be confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.”

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/71ab6710-a2d0-4639-9f7f-91be0a3abd21n%40chromium.org.

[Alexei Svitkine]

(Removing individual metrics code OWNERS from cc.)

One thing that may be relevant to you is this bit from:

https://chromium.googlesource.com/chromium/src/+/refs/heads/main/testing/variations/README.md

Note: Non-developer builds of Chromium (for example, non-Chrome browsers, or Chromium builds provided by Linux distros) should disable the testing config by either (1) specifying the GN flag disable_fieldtrial_testing_config=true, (2) specifying the --disable-field-trial-config switch, ...

(Chromium builds are meant for developer use, which may enable/disable various features that are still being tested but not necessarily ready for production use. If you're building a product based on Chromium, you likely want to disable the testing config which will use the C++ defaults for whether features are enabled or disabled - which correspond to things that are production ready.)

[Mike Taylor]

Hi Asesh - it would be really helpful if you could comment in the bug with more details about the canvas zoom bug, including known URLs (if publicly accessible) or any JS library or component names. Thx.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACwGi-7eZDs5r0DWyhuzR%3DSD20t_oxK8RQNcvyLu83ELW1Y%3DRQ%40mail.gmail.com.

[Asesh Shrestha]

Hi, I am aware of that page. I tried all of that and none worked. Like I mentioned in that post, it was only after debugging that I found out that our Chromium builds both debug and release (official)  were launched with --disable-features=EventPath but Chrome’s renderer processes were not launched with that argument which I found out using process explorer. FYI, we are using the latest and stable version of Chromium version 104.0.5112.102. Thanks

[Asesh Shrestha]

Hi, actually our users reported that issue when they were using our clients’ tool from our Chromium fork. Many reported the same issue across different clients’ tool but worked fine in Chrome. While we cannot give non-employees access to that tool. I will contact one of our clients and try to find a replicable sample, if possible. Thanks

[Alexei Svitkine]

> I tried all of that and none worked. Like I mentioned in that post, it was only after debugging that I found out that our Chromium builds both debug and release (official)  were launched with --disable-features=EventPath but Chrome’s renderer processes were not launched with that argument which I found out using process explorer.

I'm not sure what you mean by "were launched with" - do you mean your own scripts for launching Chromium were passing these flags? As normally, if you just launch a program yourself, no command line flags would be passed. But of course, there's a possibility of Chromium code itself modifying the command line object at runtime (which could show up on the command line shown in chrome://version - but not in process explorer). In particular, that's what happens if you have something enabled through about:flags.

If the browser process has a --enable-features or --disable-features passed, that state will be provided to child processes as well, but the mechanism for that is not the command line (so looking at their flags from process explorer is not relevant). It's done through shared memory.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/fe996c8b-eff8-4127-8859-7293a8ffc53bn%40chromium.org.

[Xiaocheng Hu]

Hi Asesh,

Feature owner here.

Could you comment with more details at crbug.com? Either a new bug or crbug.com/1277431 would be fine.

We are planning to remove Event.path by M109, since it's a non-standard API. The long term solution is to migrate to Event.composedPath(), which is a standard API that returns exactly the same result.

For the short term, if it happens to an enterprise product (which sounds like your case?), it's recommended to set the Enterprise Policy EventPathEnabled. It can force-enable the feature until M115, so that there's more time to migrate.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAKFU2SAGBPmu21gzn3KjPN_eZLzqGHcDFO6ERqL5VkYDu-nuKw%40mail.gmail.com.

[Asesh Shrestha]

Hi Alexie, actually I meant Chromium was passing  --disable-features=EventPath  to renderer processes which I found out when Chromium was about to launch renderer process. Our users launch our browser usually from the shortcut, so no arguments are passed manually in cases like that. But I have modified our fork to pass  --force-fieldtrials   because we have had to deal with Chromium specific issues not replicable on Chrome at all. Like I mentioned above, after disabling passing of that switch, we don't see that issue anymore. Here's the full path along with arguments captured from process explorer of both Chrome and our fork:

Our browser (Before the issue was fixed):

"C:\Program Files (x86)\CloudFactory\WorkStream\Application\workstream.exe" --type=renderer --extension-process --display-capture-permissions-policy-allowed --lang=en-US --device-scale-factor=1 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=5 --launch-time-ticks=698039976407 --mojo-platform-channel-handle=3740 --field-trial-handle=1724,i,10091040344505328847,6346652622373581066,131072 --disable-features=EventPath /prefetch:1 (Highlighted in red)

Chrome:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --type=renderer --display-capture-permissions-policy-allowed --lang=en-US --device-scale-factor=1 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=12 --launch-time-ticks=670304814762 --mojo-platform-channel-handle=6980 --field-trial-handle=1828,i,8050039470712155384,8167524653696655415,131072 /prefetch:1

Thanks

[Asesh Shrestha]

Hi Xiaocheng, I will do my best. I will have to contact our clients for a replicable sample. Thank you for your suggestion.

Thanks again