Fixes bug introduced in r28333, where we were checking if path.empty() instea...

Fixes bug introduced in r28333, where we were checking if path.empty() instead of !PathExists(path).
In addition makes background page load check.

BUG=24041
TEST=Try loading extension with content script that doesn't exist on disk, but is listed in manifest.


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

[Finnur, 2009-10-27 00:09:33]

LGTM

[Finnur, 2009-10-27 15:59:31]

LGTM with those latest changes.

[Nebojša Ćirić, 2009-10-27 18:29:46]

It just checks if the object has correct state when the resource is missing=
.

You could add additional check for the original path, which we currently
don't do (see Aaron's comment
http://codereview.chromium.org/256022/diff/3003/9098#newcode49), if you
think that would make code correct.

If you do add that check, then we'll end up with double PathExists calls fo=
r
resources - see my CL where I fixed a bug related to this check
http://codereview.chromium.org/335037/show

<http://codereview.chromium.org/335037/show>Nebojsa

On Tue, Oct 27, 2009 at 11:11 AM, Marc-Andre Decoste <mad@google.com> wrote=
:

> Still, this doesn't explain why we have the following
> test: CreateWithMissingResourceOnDisk
>
> Which makes sure that we can fetch the path to a resource that is not on
> disk... Do we need this?
>
> Thanks!
>
> BYE
> MAD
>
> On Tue, Oct 27, 2009 at 1:27 PM, Neboj=C5=A1a =C4=86iri=C4=87 <cira@chrom=
ium.org> wrote:
>
>> Extension consists of various files that are loaded on demand, like css,
>> js, icons, html pages...
>> Initial implementation used one path per resource, but then I added
>> localization logic, and that was not enough.
>>
>> Extension author could provide multiple implementation for each resource
>> (think localized icons), so we try to load them in proper order:
>> current_locale, less_specific_locale..., original path.
>>
>> Only when actual resource is needed we try to resolve the path by statin=
g
>> the file system.
>>
>> I'll try ascii art :)
>>
>> extension_root
>>    - resource1.ico
>>    + _locales
>>      + pt
>>         - resource1.ico
>>      + pt_BR
>>         - resource1.ico
>>
>> In this case, we check (in pt_BR, pt, root order) if resource1.ico exist=
s.
>>
>> Nebojsa
>>
>> On Mon, Oct 26, 2009 at 8:15 PM, Mark Mentovai <mark@chromium.org> wrote=
:
>>
>>> Marc-Andre Decoste wrote:
>>> > OK... Well... I'll let the extension guys answer that one...
>>> > The code was previously using net::FilePathToFileURL and back to
>>> FilePath to
>>> > resolve these issues before I started trying to clean it up... So I
>>> guess it
>>> > was already a problem then, right?
>>>
>>> Absolutely.
>>>
>>> It seemed like a problem when we (dmac & brettw & I) found it last
>>> week too.  It does seem like it needs to be cleaned up.  Especially if
>>> these checks are being done in the name of security, not fully
>>> accounting for all of the possibilities is pretty dangerous.
>>>
>>> Extensions folks, what's the story with these pathname checks?  I'd
>>> like to help, but I don't know anything about what an extension ought
>>> to look like on disk.
>>>
>>> Mark
>>>
>>
>>
>