The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4adc24eefa490e48807b6a6de77a31d56cc35dbc

commit 4adc24eefa490e48807b6a6de77a31d56cc35dbc
Author: James Cook <jamescook@chromium.org>
Date: Thu Feb 08 04:57:40 2018

Allow sending feedback even if the screenshot failed

Some chrome flags can break desktop media capture (e.g. chrome --mash).
This causes the "Report an issue" feedback dialog not to show up, since
the dialog waits for the screenshot to be done before opening.

Allow the dialog to open anyway, but with a blank screenshot and a
disabled "send screenshot" checkout. This way we can get feedback
reports and investigate the problem.

Bug: 807408
Test: Run chrome --mash, select Report an issue, dialog opens
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I43529532529809073a09ff4230038fcb6074bffa
Reviewed-on: https://chromium-review.googlesource.com/907693
Commit-Queue: James Cook <jamescook@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535305}
[modify] https://crrev.com/4adc24eefa490e48807b6a6de77a31d56cc35dbc/chrome/browser/resources/feedback/js/feedback.js
[modify] https://crrev.com/4adc24eefa490e48807b6a6de77a31d56cc35dbc/chrome/browser/resources/feedback/js/take_screenshot.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/de2b60037b8d588986ae97467e4202d05712f637

commit de2b60037b8d588986ae97467e4202d05712f637
Author: James Cook <jamescook@chromium.org>
Date: Fri Feb 09 22:24:14 2018

cros: Workaround touch HUD point crash under --mash

The code that collects touch HUD points calls directly into ash,
which doesn't work when ash is out-of-process. Under mash touch point
data should probably come from the window service. We're still sorting
out how ash and the window service are combined, so for now just skip
collecting this data.

This makes "Report an issue" get a little further along under --mash,
but it still doesn't work completely.

Bug: 807408
Test: manual
Change-Id: If9e5d22ef6bb15ddd8bdc7baf68accc9f168ea72
Reviewed-on: https://chromium-review.googlesource.com/912309
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Commit-Queue: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535851}
[modify] https://crrev.com/de2b60037b8d588986ae97467e4202d05712f637/chrome/browser/chromeos/system_logs/touch_log_source.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/75077638cdb3d2b098ccf5f649ec33b1c98aa8fd

commit 75077638cdb3d2b098ccf5f649ec33b1c98aa8fd
Author: James Cook <jamescook@chromium.org>
Date: Thu Feb 22 22:22:19 2018

cros: Workaround crash in Feedback tool under --mash

The feedback app uses desktop capture to take a screenshot, which
crashes in chrome --mash because it tries to use ash::Shell from the
browser process.

Just skip the screenshot under --mash. This allows users to send us
feedback reports, just missing the screenshot.

Bug:  806366 , 807408
Test: "Report an issue" works with chrome --mash with blank screenshot
Change-Id: I619ae60dd839cd87117cf7dc840c92053e3f0964
Reviewed-on: https://chromium-review.googlesource.com/927353
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Yuri Wiitala <miu@chromium.org>
Commit-Queue: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538589}
[modify] https://crrev.com/75077638cdb3d2b098ccf5f649ec33b1c98aa8fd/chrome/browser/media/webrtc/desktop_capture_access_handler.cc

Also needs to get a list of touch points, probably from window server.

Remaining dependncy here is in touch_log_source.cc:CollectTouchHudDebugLog

sheckylin@ / jamescook@ - Is this worth keeping? The touch hud is behind a command line flag, bug I imagine this might be useful? It will require adding a mojo API to fetch the data. Fortunately TouchLogSource::Fetch is already asynchronous, so it will just involve the effort of adding the mojo API somewhere and passing the data that way.

sky@ / jamescook@ - I do not think this is actually a blocker for Mash-SingleProcess since it just accesses a singleton that collects and copies data from Shell::GetAllRootWindowControllers(); it doesn't keep or pass any references or identifiers for those windows / controllers. Is that correct?

Steven, yeah, I guess it's OK for single-process mash since it's just iterating through root windows.

I've never been able to determine if anyone uses this data in feedback reports. I'm also not sure if the data is always available or only when --ash-touch-hud is passed.

If the data only shows up in feedback reports when --ash-touch-hud is passed I would just delete the feature. If it happens in all feedback reports I would add a mojo API for it.

shecklin, do you know if anyone actually uses this data from feedback reports?

The data is only generated / available when the flag is enabled.

I am wondering about supporting a potential case where a developer requests a tester or user to enable that flag, repro an issue, then send a feedback report.

Eventually I suspect that we are going to want to gather feedback report data from Ash (if we don't already?). It would probably be a good idea to do an audit, then possibly create a generic mojo API call to gather feedback report dictionaries from Ash, which could include the touch hud data.

I will put this on the back burner for now since it won't affect single process mash.

I am unsure what TouchObserverHUD is for actually. In ChromeOS we usually use only the other 3 data:

const char kDeviceStatusLogDataKey[] = "hack-33025-touchpad";
const char kTouchpadEventLogDataKey[] = "hack-33025-touchpad_activity";
const char kTouchscreenEventLogDataKey[] = "hack-33025-touchscreen_activity";

Maybe it would be better to talk to the owner of that class.

It looks like the primary contributors are +sadrul@ and +mohsen@. Any thoughts?