Gave native File Browser file handlers higher priority than 3rd party handlers.

Gave native File Browser file handlers higher priority than 3rd party handlers.

In the File Browser if there are several actions available for a file then the most recently used one becomes the default (it is invoked on double click etc). On a fresh profile when all timestamps are equal this is a matter of chance. 
The patch gives higher priority to the actions of the File Browser (only as long as timestamps are equal).

BUG=chromium-os:27216
TEST=Start on a fresh profile, observe that "View" is shown for an image file, not "Upload to Picasa"


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=126711

[Vladislav Kaznacheev, 2012-03-13 16:28:27]

Please review

[Vladislav Kaznacheev, 2012-03-14 11:12:02]

Adding Sergey.

[SeRya, 2012-03-14 11:44:57]

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
File chrome/browser/chromeos/extensions/file_handler_util.h (right):

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
chrome/browser/chromeos/extensions/file_handler_util.h:45: const std::string&
privileged_extension_id,
Could this parameter different from kFileBrowserDomain? If not let's use the
constant instead of variable and not pretend we have flexibility here.

[Vladislav Kaznacheev, 2012-03-14 12:01:05]

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
File chrome/browser/chromeos/extensions/file_handler_util.h (right):

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
chrome/browser/chromeos/extensions/file_handler_util.h:45: const std::string&
privileged_extension_id,
It is not about flexibility but about dependencies. Currently
file_handler_util.cc does not include file_manager_util.h and I like it.
On 2012/03/14 11:44:57, SeRya wrote:
> Could this parameter different from kFileBrowserDomain? If not let's use the
> constant instead of variable and not pretend we have flexibility here.

[SeRya, 2012-03-14 12:19:22]

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
File chrome/browser/chromeos/extensions/file_handler_util.h (right):

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
chrome/browser/chromeos/extensions/file_handler_util.h:45: const std::string&
privileged_extension_id,
Could we resolve the dependency issue not touching public API?
file_handler_util.cc may be shouldn't know File Manager but it may distinguish
component extensions from installed extensions.

On 2012/03/14 12:01:05, Vladislav Kaznacheev wrote:
> It is not about flexibility but about dependencies. Currently
> file_handler_util.cc does not include file_manager_util.h and I like it.
> On 2012/03/14 11:44:57, SeRya wrote:
> > Could this parameter different from kFileBrowserDomain? If not let's use the
> > constant instead of variable and not pretend we have flexibility here.
>

[Vladislav Kaznacheev, 2012-03-14 12:28:07]

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
File chrome/browser/chromeos/extensions/file_handler_util.h (right):

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
chrome/browser/chromeos/extensions/file_handler_util.h:45: const std::string&
privileged_extension_id,
Checking for component extensions is not enough. The bug that I am fixing is
about the conflict between File Manager and Picasa Uploader which is a component
extension too.

On 2012/03/14 12:19:22, SeRya wrote:
> Could we resolve the dependency issue not touching public API?
> file_handler_util.cc may be shouldn't know File Manager but it may distinguish
> component extensions from installed extensions.
> 
> On 2012/03/14 12:01:05, Vladislav Kaznacheev wrote:
> > It is not about flexibility but about dependencies. Currently
> > file_handler_util.cc does not include file_manager_util.h and I like it.
> > On 2012/03/14 11:44:57, SeRya wrote:
> > > Could this parameter different from kFileBrowserDomain? If not let's use
the
> > > constant instead of variable and not pretend we have flexibility here.
> > 
>

[dgozman, 2012-03-14 13:31:11]

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
File chrome/browser/chromeos/extensions/file_handler_util.h (right):

https://chromiumcodereview.appspot.com/9692049/diff/1/chrome/browser/chromeos...
chrome/browser/chromeos/extensions/file_handler_util.h:45: const std::string&
privileged_extension_id,
AFAIK, Picasa Uploader is not a component extension.
However, I'm fine with this approach.

On 2012/03/14 12:28:07, Vladislav Kaznacheev wrote:
> Checking for component extensions is not enough. The bug that I am fixing is
> about the conflict between File Manager and Picasa Uploader which is a
component
> extension too.
> 
> On 2012/03/14 12:19:22, SeRya wrote:
> > Could we resolve the dependency issue not touching public API?
> > file_handler_util.cc may be shouldn't know File Manager but it may
distinguish
> > component extensions from installed extensions.
> > 
> > On 2012/03/14 12:01:05, Vladislav Kaznacheev wrote:
> > > It is not about flexibility but about dependencies. Currently
> > > file_handler_util.cc does not include file_manager_util.h and I like it.
> > > On 2012/03/14 11:44:57, SeRya wrote:
> > > > Could this parameter different from kFileBrowserDomain? If not let's use
> the
> > > > constant instead of variable and not pretend we have flexibility here.
> > > 
> > 
>

[Vladislav Kaznacheev, 2012-03-14 13:35:18]

After discussing this with Sergey I am convinced that a shorter patch is better
even if it is not so perfect dependency-wise.

PTAL.

[SeRya, 2012-03-14 18:05:59]

lgtm

[commit-bot: I haz the power, 2012-03-14 18:13:48]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kaznacheev@chromium.org/9692049/8001

[commit-bot: I haz the power, 2012-03-14 20:02:56]

Change committed as 126711