First cut at UI for saving net_logs data into a temporary file on

First cut at UI for saving net_logs data into a temporary file on
Mobile (Android and iOS). 

Added a new page chrome://net-export to start/stop/send the net_log
for mobile platforms.

Button "Start Saving (after deleting old data)" will start saving to a
temporary file in "NetLog" directory in Temp directory. It deletes all
the old temporary files that were in that directory before creating a
new temporty file. It is a no-op if we are already saving data into a
file.

Button "Stop Saving Data" closes the temporary file so that it could
be mailed. It is a no-op if we haven't started saving data into a
file.

Button "Send Data" emails the data file if a temporary file exists in
"NetLog" directory. It is a no-op if there is no file.

There is only a single temporary file into which we log the
data. NetLog data is saved in the browser process. Logging of net_log
data behaves similar to the command line option --log-net-log.

If chrome://net-export is accessed in multiple tabs, action in first
tab wins. If Stop is clicked in any tab, logging stops. If start is
clicked in any tab, net logging starts.

mmenke@ and/or eroman@ for chrome\browser\resources and webui changes. 
jar@ for net_log_temp_file changes.
jhawkins@chromium.org for chrome\browser\ui\webui and chrome\browser\resources
OWNERS stamp.

R=jar@chromium.org, mmenke@chromium.org
BUG=151212

[ramant (doing other things), 2012-12-20 22:52:32]

droger@, qsr@ and yfriedman@ would appreciate if you could take a look at
android/iOS related changes.

thanks
raman

[mmenke, 2012-12-27 20:43:04]

[+eroman]

I have not yet fully reviewed this.  I intend to take a closer look tomorrow.

I'm not convinced having a tab in net-internals for this is the best approach.

One alternative would be to have something like "about:net-internals/mobile",
and load just a subset of the net-internals scripts (browser_bridge, log dumping
code (And the displaying code, since that's needed for filtering out cookies),
util.js, some of main.js).

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/net/net_log...
File chrome/browser/net/net_log_logger.cc (right):

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/net/net_log...
chrome/browser/net/net_log_logger.cc:46: void
NetLogLogger::StopObserving(net::NetLog* net_log) {
No need to take a net_log as a parameter here.  Can just do:

net_log()->RemoveThreadSafeObserver(this);

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/net/net_log...
File chrome/browser/net/net_log_temp_file.h (right):

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/net/net_log...
chrome/browser/net/net_log_temp_file.h:49: static NetLogTempFile* GetInstance();
What's the motivation for making this a Singleton?

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/net/net_log...
chrome/browser/net/net_log_temp_file.h:54: ~NetLogTempFile();
If we're going to make this a Singleton, these should be private (You've already
friended DefaultSingletonTraits, as you would need to).

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/ui/webui/ne...
File chrome/browser/ui/webui/net_internals/net_internals_ui.cc (right):

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/ui/webui/ne...
chrome/browser/ui/webui/net_internals/net_internals_ui.cc:1745: #if
!defined(OS_IOS)
This seems a somewhat random thing to exclude on iOS.  The events view may be
useful on the larger screen of iPods, no?  Are you just worried about memory
usage?

[ramant (doing other things), 2013-01-04 01:47:28]

Hi Matt,
  As you have suggested, added mobile.html to display the Mobile tab to
start/stop/send net logs (it can be accessed as
chrome://net-internals/mobile.html). 

  mobile.html works on Desktop also to log net_log entries into a file (thanks
to eroman for the suggestion). 

  Displayed the file name in Debug mode only (jar). 

  Because all net_logging is taking place on IO thread (the command line
argument to save the data to a file also happens on IO thread), changed the code
to run only on IO thread (thanks to jar for the suggestion).

https://chromiumcodereview.appspot.com/11635023/diff/2006/chrome/browser/net/...
File chrome/browser/net/net_log_logger.cc (right):

https://chromiumcodereview.appspot.com/11635023/diff/2006/chrome/browser/net/...
chrome/browser/net/net_log_logger.cc:46: void
NetLogLogger::StopObserving(net::NetLog* net_log) {
On 2012/12/27 20:43:05, Matt Menke wrote:
> No need to take a net_log as a parameter here.  Can just do:
> 
> net_log()->RemoveThreadSafeObserver(this);

Done.

https://chromiumcodereview.appspot.com/11635023/diff/2006/chrome/browser/net/...
File chrome/browser/net/net_log_temp_file.h (right):

https://chromiumcodereview.appspot.com/11635023/diff/2006/chrome/browser/net/...
chrome/browser/net/net_log_temp_file.h:49: static NetLogTempFile* GetInstance();
On 2012/12/27 20:43:05, Matt Menke wrote:
> What's the motivation for making this a Singleton?

Made it a single to work with chrome://net-internals being opened in multiple
tabs.

https://chromiumcodereview.appspot.com/11635023/diff/2006/chrome/browser/net/...
chrome/browser/net/net_log_temp_file.h:54: ~NetLogTempFile();
On 2012/12/27 20:43:05, Matt Menke wrote:
> If we're going to make this a Singleton, these should be private (You've
already
> friended DefaultSingletonTraits, as you would need to).

Done.

https://chromiumcodereview.appspot.com/11635023/diff/2006/chrome/browser/ui/w...
File chrome/browser/ui/webui/net_internals/net_internals_ui.cc (right):

https://chromiumcodereview.appspot.com/11635023/diff/2006/chrome/browser/ui/w...
chrome/browser/ui/webui/net_internals/net_internals_ui.cc:1745: #if
!defined(OS_IOS)
On 2012/12/27 20:43:05, Matt Menke wrote:
> This seems a somewhat random thing to exclude on iOS.  The events view may be
> useful on the larger screen of iPods, no?  Are you just worried about memory
> usage?

Added code in JavaScript not to store pending_entries.

Our intention was not to use memory in IOS where we run in single process mode.

Done.

[mmenke, 2013-01-04 16:22:09]

I'm sorry, for some reason, I was thinking we were sharing log filtering code
with net-internals.

Since we're not doing this, do we even gain anything from integrating this with
net-internals?  Seems like we don't share any of the behaviors, other than
having communication with the browser.  This being the case, I'm thinking it
makes more sense to make a separate WebUI page.  It can even all run on the UI
thread - NetLog observers and the ChromeNetLog can safely be mucked with on the
UI thread.

I'm sorry again for sending you in this direction - if we needed to share any
code with net-internals, I think this approach (With some work on clearly
differentiating the mobile / non-mobile / shared JS code) would be the right
approach, but since we aren't using anything from net-internals...

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/net/net_log...
File chrome/browser/net/net_log_temp_file.h (right):

https://codereview.chromium.org/11635023/diff/2006/chrome/browser/net/net_log...
chrome/browser/net/net_log_temp_file.h:49: static NetLogTempFile* GetInstance();
On 2013/01/04 01:47:28, ramant wrote:
> On 2012/12/27 20:43:05, Matt Menke wrote:
> > What's the motivation for making this a Singleton?
> 
> Made it a single to work with chrome://net-internals being opened in multiple
> tabs.

How much do we care about that use case?  I've been instilled with a dislike of
singletons unless absolutely necessary, and I'm not convinced it's absolutely
necessary here.

If we're really concerned about it, there's only one ChromeNetLog, and we could
expose these functions there instead, or have it own the NetLogTempFile, and
expose it directly.

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/net/net_lo...
File chrome/browser/net/net_log_logger.h (right):

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/net/net_lo...
chrome/browser/net/net_log_logger.h:46: net::NetLog* net_log_;
This isn't needed.  NetLog::ThreadSafeObserver has a net_log() function that
returns the same thing.

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/net/net_lo...
File chrome/browser/net/net_log_temp_file.h (right):

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/net/net_lo...
chrome/browser/net/net_log_temp_file.h:53: NetLogTempFile();
This shouldn't be public for a singleton.

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/resources/...
File chrome/browser/resources/net_internals/mobile.html (right):

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/resources/...
chrome/browser/resources/net_internals/mobile.html:15: <link rel="stylesheet"
href="tab_switcher_view.css">
To reduce redistributable size, we should be putting these in something like
chrome://net-internals/shared.css.  Same with shared JS and HTML files.  Think
this is simple enough that it can be done in this CL, though if you prefer to do
it in a followup CL, that's fine.

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/resources/...
chrome/browser/resources/net_internals/mobile.html:18: <script
src="chrome://net-internals/mobile.js"></script>
Looks like you updated net_internals_resources.grd, but forgot to include it in
this CL.

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/resources/...
File chrome/browser/resources/net_internals/mobile_main.js (right):

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/resources/...
chrome/browser/resources/net_internals/mobile_main.js:77: false, true);
You're planning on getting rid of these in a later pass (Possibly in another
CL), right?

https://codereview.chromium.org/11635023/diff/28001/chrome/browser/resources/...
chrome/browser/resources/net_internals/mobile_main.js:187: function
ConstantsObserver() {}
Think it's worth moving the constants stuff to a shared js file, though fine to
do it in a followup CL.