Add new API function: feedbackPrivate.readLogSource

chrome/common/extensions/api/feedback_private.idl

Index: chrome/common/extensions/api/feedback_private.idl
diff --git a/chrome/common/extensions/api/feedback_private.idl b/chrome/common/extensions/api/feedback_private.idl
index fe52a422dc39b24ef3471382e71ff501d177bdb8..03dfdb2cbde65dc261adc1ed612e57e4014745ac 100644
--- a/chrome/common/extensions/api/feedback_private.idl
+++ b/chrome/common/extensions/api/feedback_private.idl
@@ -96,6 +96,8 @@ namespace feedbackPrivate {
       void(SystemInformation[] systemInformation);
   callback SendFeedbackCallback = void(Status status);
   callback GetStringsCallback = void(object result);
+  callback ReadLinesFromFileCallback =
+      void (long numBytesRead, DOMString[] logLines);
 
   interface Functions {
     // Returns the email of the currently active or logged in user.
@@ -116,6 +118,19 @@ namespace feedbackPrivate {
     // Logs whether the user accepted a prompt to try the Software Removal
     // Tool.
     static void logSrtPromptResult(SrtPromptResult result);
+
+    // Reads from a log file |filename|, starting from byte offset

[rkc, 2017/04/26 03:08:43]

Instead of reading any arbitrary filename, can we restrict this to known log
sources, selected based on an enum?

[Simon Que, 2017/04/26 14:08:19]

That's a good idea. I was originally going to use an internal whitelist, in C++
code. And this was going to be CrOS-specific. The list of files would be
something like:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/system_lo...

Would it still make sense to put an enum def here, given that this will only
work on Chrome OS, and that the enums represent log file paths on Chrome OS?

[rkc, 2017/04/26 16:17:17]

This API will only ever work on Chrome OS. Apps on non-chrome OS platforms are
deprecated.

[Simon Que, 2017/04/26 18:42:44]

What about extensions? feedbackPrivate API is supported for extensions.

[rkc, 2017/04/26 18:46:33]

The 'rest' of this API will continue to work on other platforms, I mean this
function specifically.

In either case, this is a private API, we control the usage. There are no plans
on using this from any other app.

[Simon Que, 2017/04/26 19:46:39]

Done.

+    // |offsetBytes|, and reading up to |numBytesToRead| bytes. If the
+    // file is not allowed to be read, or is otherwise unreadable,
+    // returns an empty array. If |numBytesToRead| is 0, reads all the
+    // way to the end of file.
+    //
+    // In addition, can only return whole lines. Reading of only a part
+    // of a line is not allowed. Partial lines will not be returned.
+    static void readLinesFromFile(DOMString filename,
+                                  long offsetBytes,

[rkc, 2017/04/26 03:08:43]

This is not quite a logging API anymore. Instead of getting into things like
offset and number of bytes, can we instead just have the API keep track of how
much you've read?

How about something like,

readLogSource(LogSource source, bool incremental, ReadCallback callback)

?

[Simon Que, 2017/04/26 14:08:19]

I realized the following problem...

If there is a tracking mechanism, what happens when it gets called from multiple
apps? A few possibilities:
1. Assume that it will only be called from one app. Not a very secure
assumption.
2. Provide a token to the first caller that it must subsequently pass in each
time. This allows only the first caller to have access to a particular file over
this API.
3. Similar to #2 but allow multiple callers to track a single file independently
(up to a limited number of tracking counters), each with its own token.

[rkc, 2017/04/26 16:17:17]

This will either be a private API or be only run in Kiosk Mode, so it is
unlikely that two apps will call this API (it is still possible, but then both
apps would be provided by the enterprise admin, since the only way you can have
multiple apps in Kiosk mode is via having dependent apps/extensions).

Still, having a tracking ID for the read in progress is a good idea regardless -
so maybe something like an optional "readerId" that you can pass in to
subsequent calls.

[Simon Que, 2017/04/26 18:42:44]

feedbackPrivate API is whitelisted for both the Hotrod app and the feedback UI.

[rkc, 2017/04/26 18:46:33]

Right, the feedback UI will not use this API. There is no reason for it to.

[Simon Que, 2017/04/26 19:46:39]

Done.

+                                  long numBytesToRead,
+                                  ReadLinesFromFileCallback callback);
   };
 
   interface Events {