Drop hover:on-demand support & let touch-screens report "none" instead.

Drop hover:on-demand support & let touch-screens report "none" instead.

The "hover" and "any-hover" media query features was originally speced to
have three possible values {"none", "on-demand", "hover"}. The "on-demand"
value has been removed from the spec recently:
  https://drafts.csswg.org/mediaqueries-4/#hover
so we are considering removing support for this value.

Through this CL, chromium drops the support for the "on-demand" value.
Touch-screens will now report "none" instead to match mobile Safari.

Blink intent thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-sTmxMpl6iI

BUG=654861
Review-Url: https://codereview.chromium.org/2673963002
Cr-Commit-Position: refs/heads/master@{#459223}
Committed: https://chromium.googlesource.com/chromium/src/+/344035e6942d313099c3ceb741f2eb8231de1a2c

[mustaq, 2017-02-03 20:26:18]

Description was changed from

==========
Stop reporting hover:on-demand for touch-screens.

The "hover" and "any-hover" media query features was originally speced to
have three possible values {"none", "on-demand", "hover"}. The "on-demand"
value has been removed from the spec recently:
  https://drafts.csswg.org/mediaqueries-4/#hover
so we are considering removing support for this value.

Through this CL, chromium will stop reporting "on-demand" value for
touch-screens. This CL also adds a UseCounter to evaluate the risk of removing
complete support.

BUG=654861
==========

to

==========
Make touch-screens report hover:none instead of hover:on-demand.

The "hover" and "any-hover" media query features was originally speced to
have three possible values {"none", "on-demand", "hover"}. The "on-demand"
value has been removed from the spec recently:
  https://drafts.csswg.org/mediaqueries-4/#hover
so we are considering removing support for this value.

Through this CL, chromium will report "none" instead of "on-demand" value for
touch-screens to match mobile Safari, thus stop reporting "on-demand"
completely. This CL also adds a UseCounter to evaluate the risk of removing
complete support.

BUG=654861
==========

[mustaq, 2017-02-03 20:26:36]

mustaq@chromium.org changed reviewers:
+ bokan@chromium.org

[mustaq, 2017-02-03 20:26:37]

ptal

[mustaq, 2017-02-03 20:27:21]

The CQ bit was checked by mustaq@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-03 20:28:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mustaq, 2017-02-03 20:28:29]

The CQ bit was unchecked by mustaq@chromium.org

[mustaq, 2017-02-03 20:38:02]

The CQ bit was checked by mustaq@chromium.org

[commit-bot: I haz the power, 2017-02-03 20:38:58]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-03 20:38:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-03 20:38:59]

No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
Committers are members of the group "project-chromium-committers".
Note that this has nothing to do with OWNERS files.

[mustaq, 2017-02-03 20:40:31]

The CQ bit was checked by mustaq@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-03 20:41:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-03 20:59:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-03 20:59:15]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[mustaq, 2017-02-03 22:33:02]

The CQ bit was checked by mustaq@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-03 22:33:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-03 22:39:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-03 22:39:05]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[mustaq, 2017-02-06 15:06:36]

The CQ bit was checked by mustaq@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-06 15:06:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[bokan, 2017-02-06 15:53:50]

lgtm % nit

https://codereview.chromium.org/2673963002/diff/40001/ui/android/java/src/org...
File ui/android/java/src/org/chromium/ui/base/TouchDevice.java (right):

https://codereview.chromium.org/2673963002/diff/40001/ui/android/java/src/org...
ui/android/java/src/org/chromium/ui/base/TouchDevice.java:54: *         the
hover-types supported by the device, as the union (bitwise OR) of HoverType bits
Nit: rewrap the comment (much of this line can fit above).

[mustaq, 2017-02-06 16:10:33]

mustaq@chromium.org changed reviewers:
+ avi@chromium.org, rbyers@chromium.org

[mustaq, 2017-02-06 16:10:34]

ptal, need owner's review:
  rbyers: third_party/WebKit/*
  avi: content/public/* and ui/*

https://codereview.chromium.org/2673963002/diff/40001/ui/android/java/src/org...
File ui/android/java/src/org/chromium/ui/base/TouchDevice.java (right):

https://codereview.chromium.org/2673963002/diff/40001/ui/android/java/src/org...
ui/android/java/src/org/chromium/ui/base/TouchDevice.java:54: *         the
hover-types supported by the device, as the union (bitwise OR) of HoverType bits
On 2017/02/06 15:53:50, bokan wrote:
> Nit: rewrap the comment (much of this line can fit above).

Done.

[Rick Byers, 2017-02-06 16:35:22]

This change is effectively equivalent to completely removing hover:on-demand
support, right?  Even though we still parse it, it'll never actually get set so
should behave similarly to an unrecognized value I think?

Reporting hover:none INSTEAD of hover:on-demand is the thing that has potential
web compat impact (so needs some measurement/intent).  This change will break
sites (gmail?) which are relying on 'hover:on-demand' to enable some touchscreen
support.  I think the risk is low, so we can probably do it easily, but we still
need some compat data first and an intent-to-remove.

What I was suggesting in
https://bugs.chromium.org/p/chromium/issues/detail?id=654861#c9 was to make
'hover:none' (and 'any-hove:none') true on touchscreen-only devices without
changing the behavior of 'hover:on-demand'.  But if you prefer to make all the
web-exposed changes in a single simpler step that's OK with me too (then we'd
just land the UseCounter now).

In order to reason about how any-hover should behave according to the spec, I
think of it this way:

'any-hover:hover' is used to show UI elements which are valuable when SOME
pointer device supports hovering (eg. :hover styles).

'any-hover:none' is used to show UI elements when SOME pointer devices does NOT
support hovering (eg. extra buttons that trigger behavior otherwise behind
:hover styles).

I know it's confusing for both to be true at once (especially given the word
"none") on touchscreen laptops, but that's the design in the spec.

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
File ui/base/touch/touch_device_linux.cc (right):

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
ui/base/touch/touch_device_linux.cc:31: return HOVER_TYPE_HOVER;
I think we still want HOVER_TYPE_NONE | HOVER_TYPE_HOVER in the
TouchDevicePresent case.  I.e. 'any-hover:none' is still expected to evaluate to
true on a touchscreen laptop.

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
File ui/base/touch/touch_device_win.cc (right):

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
ui/base/touch/touch_device_win.cc:35: return (GetSystemMetrics(SM_MOUSEPRESENT)
!= 0) ? HOVER_TYPE_HOVER
Again there should still be three possible states here:

Mouse-only: HOVER_TYPE_HOVER
Touch-only: HOVER_TYPE_NONE
No input devices: HOVER_TYPE_NONE
Mouse+touch: HOVER_TYPE_HOVER | HOVER_TYPE_NONE

[mustaq, 2017-02-06 17:13:02]

Done with the touch+mouse case, ptal if this is what you meant.

Note one subtle Android-only change for the touch+mouse case:
touch_device_android used to report primary-hover=on_demand before, now we are
reporting primary-hover=hover. I think this is fine because we were not
consistent with other platforms before (and this is a rare case) but still
wanted to call this out in case you think we should defer this change too until
our "intent to remove".

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
File ui/base/touch/touch_device_linux.cc (right):

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
ui/base/touch/touch_device_linux.cc:31: return HOVER_TYPE_HOVER;
On 2017/02/06 16:35:22, Rick Byers (slow) wrote:
> I think we still want HOVER_TYPE_NONE | HOVER_TYPE_HOVER in the
> TouchDevicePresent case.  I.e. 'any-hover:none' is still expected to evaluate
to
> true on a touchscreen laptop.

Done.

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
File ui/base/touch/touch_device_win.cc (right):

https://codereview.chromium.org/2673963002/diff/60001/ui/base/touch/touch_dev...
ui/base/touch/touch_device_win.cc:35: return (GetSystemMetrics(SM_MOUSEPRESENT)
!= 0) ? HOVER_TYPE_HOVER
On 2017/02/06 16:35:22, Rick Byers (slow) wrote:
> Again there should still be three possible states here:
> 
> Mouse-only: HOVER_TYPE_HOVER
> Touch-only: HOVER_TYPE_NONE
> No input devices: HOVER_TYPE_NONE
> Mouse+touch: HOVER_TYPE_HOVER | HOVER_TYPE_NONE

Done.

[mustaq, 2017-02-06 20:13:06]

We decided to commit the counter-only change now, crrev.com/2678933002.

I will leave this CL around for the final cleanup (assuming the counter will
show low usage of "on-demand").

[mustaq, 2017-03-20 16:20:26]

Description was changed from

==========
Make touch-screens report hover:none instead of hover:on-demand.

The "hover" and "any-hover" media query features was originally speced to
have three possible values {"none", "on-demand", "hover"}. The "on-demand"
value has been removed from the spec recently:
  https://drafts.csswg.org/mediaqueries-4/#hover
so we are considering removing support for this value.

Through this CL, chromium will report "none" instead of "on-demand" value for
touch-screens to match mobile Safari, thus stop reporting "on-demand"
completely. This CL also adds a UseCounter to evaluate the risk of removing
complete support.

BUG=654861
==========

to

==========
Drop hover:on-demand support & let touch-screens report "none" instead.

The "hover" and "any-hover" media query features was originally speced to
have three possible values {"none", "on-demand", "hover"}. The "on-demand"
value has been removed from the spec recently:
  https://drafts.csswg.org/mediaqueries-4/#hover
so we are considering removing support for this value.

Through this CL, chromium drops the support for the "on-demand" value.
Touch-screens will now report "none" instead to match mobile Safari.

Blink intent thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-sTmxMpl6iI

BUG=654861
==========

[mustaq, 2017-03-20 16:29:06]

rbyers@ & bokan@: ptal, removed "on-demand" following the approved intent.

[mustaq, 2017-03-20 16:29:59]

Patchset #6 (id:90001) has been deleted

[mustaq, 2017-03-20 16:30:18]

The CQ bit was checked by mustaq@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-20 16:30:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Avi (use Gerrit), 2017-03-20 16:55:10]

On 2017/03/20 16:29:06, mustaq wrote:
> rbyers@ & bokan@: ptal, removed "on-demand" following the approved intent.

LGTM stamp

[commit-bot: I haz the power, 2017-03-20 18:02:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-20 18:02:11]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Rick Byers, 2017-03-21 20:47:17]

https://codereview.chromium.org/2673963002/diff/130001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/PointerProperties.h (right):

https://codereview.chromium.org/2673963002/diff/130001/third_party/WebKit/pub...
third_party/WebKit/public/platform/PointerProperties.h:18: enum HoverType {
HoverTypeNone = 1 << 0, HoverTypeHover = 1 << 1 };
nit: keep style of one value per line (unless style checker is saying
otherwise?)

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
File ui/base/touch/touch_device_android.cc (left):

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
ui/base/touch/touch_device_android.cc:49: return HOVER_TYPE_ON_DEMAND;
There's a subtle change in semantics here.  Note that unlike on Windows, on
Android we were always considering touch "primary" over "mouse".  Previously
when both touch and mouse were present we'd have pointer:coarse and
hover:on-demand.  Now in that case it seems we'd have pointer:coarse and
hover:hover, which seems inconsistent (is the primary pointer a hovering coarse
pointer?).

Assuming we want to stick with always considering touch "primary" on android,
then I think you want this here:
if (available_hover_types & HOVER_TYPE_NONE)	
      return HOVER_TYPE_NONE;

Then the only way you ever get hover:hover on Android is when there's no
touchscreen at all and only a mouse.

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
ui/base/touch/touch_device_android.cc:52: DCHECK_EQ(available_hover_types,
HOVER_TYPE_NONE);
This isn't a new problem, but I believe this DCHECK isn't necessarily true. 
Looking at the Java code, an Android device with neither a mouse or touchscreen
will have available_hover_times==0 (which is not HOVER_TYPE_NONE).  Perhaps just
remove the DCHECK?  I think returning HOVER_TYPE_NONE in both the no device and
touch-only cases is what we want here anyway.

[mustaq, 2017-03-22 14:31:30]

https://codereview.chromium.org/2673963002/diff/130001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/PointerProperties.h (right):

https://codereview.chromium.org/2673963002/diff/130001/third_party/WebKit/pub...
third_party/WebKit/public/platform/PointerProperties.h:18: enum HoverType {
HoverTypeNone = 1 << 0, HoverTypeHover = 1 << 1 };
On 2017/03/21 20:47:17, Rick Byers wrote:
> nit: keep style of one value per line (unless style checker is saying
> otherwise?)

I also find it a bit unreadable but "git cl format" wants this!

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
File ui/base/touch/touch_device_android.cc (left):

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
ui/base/touch/touch_device_android.cc:49: return HOVER_TYPE_ON_DEMAND;
On 2017/03/21 20:47:17, Rick Byers wrote:
> There's a subtle change in semantics here.  Note that unlike on Windows, on
> Android we were always considering touch "primary" over "mouse".  Previously
> when both touch and mouse were present we'd have pointer:coarse and
> hover:on-demand.  Now in that case it seems we'd have pointer:coarse and
> hover:hover, which seems inconsistent (is the primary pointer a hovering
coarse
> pointer?).
> 
> Assuming we want to stick with always considering touch "primary" on android,
> then I think you want this here:
> if (available_hover_types & HOVER_TYPE_NONE)	
>       return HOVER_TYPE_NONE;
> 
> Then the only way you ever get hover:hover on Android is when there's no
> touchscreen at all and only a mouse.

Yes, I noted this subtle change in #msg25 above but I had ruled it out as
uncommon. Your suggestion seems better. Done.

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
ui/base/touch/touch_device_android.cc:52: DCHECK_EQ(available_hover_types,
HOVER_TYPE_NONE);
On 2017/03/21 20:47:17, Rick Byers wrote:
> This isn't a new problem, but I believe this DCHECK isn't necessarily true. 
> Looking at the Java code, an Android device with neither a mouse or
touchscreen
> will have available_hover_times==0 (which is not HOVER_TYPE_NONE).  Perhaps
just
> remove the DCHECK?  I think returning HOVER_TYPE_NONE in both the no device
and
> touch-only cases is what we want here anyway.

Did you mean some Java code other than TouchDevice.java:89? I have changed the
DCHECK to match your comment above but this code shouldn't see any unset
hover-types I believe.

[Rick Byers, 2017-03-23 19:27:33]

LGTM

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
File ui/base/touch/touch_device_android.cc (left):

https://codereview.chromium.org/2673963002/diff/130001/ui/base/touch/touch_de...
ui/base/touch/touch_device_android.cc:52: DCHECK_EQ(available_hover_types,
HOVER_TYPE_NONE);
On 2017/03/22 14:31:29, mustaq wrote:
> On 2017/03/21 20:47:17, Rick Byers wrote:
> > This isn't a new problem, but I believe this DCHECK isn't necessarily true. 
> > Looking at the Java code, an Android device with neither a mouse or
> touchscreen
> > will have available_hover_times==0 (which is not HOVER_TYPE_NONE).  Perhaps
> just
> > remove the DCHECK?  I think returning HOVER_TYPE_NONE in both the no device
> and
> > touch-only cases is what we want here anyway.
> 
> Did you mean some Java code other than TouchDevice.java:89? I have changed the
> DCHECK to match your comment above but this code shouldn't see any unset
> hover-types I believe.

Ah, sorry - I missed the code that was overwriting the '0' value with the NONE
one.  Seems a little weird, but OK that means I was wrong and the DHECK is
guaranteed to be true.  Thanks!

[mustaq, 2017-03-23 19:35:06]

The CQ bit was checked by mustaq@chromium.org

[mustaq, 2017-03-23 19:35:07]

The patchset sent to the CQ was uploaded after l-g-t-m from bokan@chromium.org,
avi@chromium.org, rbyers@chromium.org
Link to the patchset: https://codereview.chromium.org/2673963002/#ps170001
(title: "Fixed a "yikes!"")

[commit-bot: I haz the power, 2017-03-23 19:35:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-23 20:17:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-23 20:17:05]

Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[mustaq, 2017-03-23 20:18:57]

The CQ bit was checked by mustaq@chromium.org

[commit-bot: I haz the power, 2017-03-23 20:19:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-23 21:20:20]

CQ is committing da patch.

Bot data: {"patchset_id": 170001, "attempt_start_ts": 1490300337484260,
"parent_rev": "7742bafdff7eb65a0528f68a37545da0a89be113", "commit_rev":
"344035e6942d313099c3ceb741f2eb8231de1a2c"}

[commit-bot: I haz the power, 2017-03-23 21:21:07]

Description was changed from

==========
Drop hover:on-demand support & let touch-screens report "none" instead.

The "hover" and "any-hover" media query features was originally speced to
have three possible values {"none", "on-demand", "hover"}. The "on-demand"
value has been removed from the spec recently:
  https://drafts.csswg.org/mediaqueries-4/#hover
so we are considering removing support for this value.

Through this CL, chromium drops the support for the "on-demand" value.
Touch-screens will now report "none" instead to match mobile Safari.

Blink intent thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-sTmxMpl6iI

BUG=654861
==========

to

==========
Drop hover:on-demand support & let touch-screens report "none" instead.

The "hover" and "any-hover" media query features was originally speced to
have three possible values {"none", "on-demand", "hover"}. The "on-demand"
value has been removed from the spec recently:
  https://drafts.csswg.org/mediaqueries-4/#hover
so we are considering removing support for this value.

Through this CL, chromium drops the support for the "on-demand" value.
Touch-screens will now report "none" instead to match mobile Safari.

Blink intent thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-sTmxMpl6iI

BUG=654861

Review-Url: https://codereview.chromium.org/2673963002
Cr-Commit-Position: refs/heads/master@{#459223}
Committed:
https://chromium.googlesource.com/chromium/src/+/344035e6942d313099c3ceb741f2...
==========

[commit-bot: I haz the power, 2017-03-23 21:21:08]

Committed patchset #9 (id:170001) as
https://chromium.googlesource.com/chromium/src/+/344035e6942d313099c3ceb741f2...