New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 757011 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Web accessible resources are case sensitive

Reported by priyansh...@gmail.com, Aug 18 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce the problem:
1. Create a sample Chrome extension with web accessible resources
2. in our scenario the resource is a local web page "Example.html"
3. Make calls in extension to load the resource using command like: chrome.tabs.update(tabId, {url:"EXAMPLE.HTML"})

What is the expected behavior?

What went wrong?
Instead of navigating to Example.html in our extension, we see an error while navigation and are taken to chrome-extension://invalid

Did this work before? Yes Chrome 59

Chrome version: 60.0.3112.101  Channel: stable
OS Version: 10.0
Flash Version: 

Not sure if we have decided from chrome 60 that the web accessible resources to be case sensitive.
 

Comment 1 by woxxom@gmail.com, Aug 18 2017

The old behavior sounds like a bug.
Case-sensitivity of URLs is the expected behavior according to the specification:
https://www.w3.org/TR/WD-html40-970708/htmlweb.html

Comment 2 by l...@chromium.org, Aug 20 2017

Components: -Platform>DevTools Platform>Extensions>API
Thanks for the report.  Maybe someone on the Extensions team knows?

In this SO post, a user with a similar situation fixed it by adding "the file to the "web_accessible_resources" section in the manifest file".  Could you please check if that works?
https://stackoverflow.com/questions/12359608/chrome-tabs-update-redirects-to-chrome-extension-invalid
Thank you for getting back.

We already had those in the web accessible resources in manifest json file.
We fixed this by making the resources usage case sensitive, and it works. I wa wondering if this was a chrome issue or will this be a expected behavior going forward
Cc: l...@chromium.org
Labels: Needs-Triage-M60
luoe@,

Could you please update the thread as per comment#3?
Thanks in advance..!

Comment 5 by l...@chromium.org, Aug 29 2017

Cc: rdevlin....@chromium.org
Components: Platform>Extensions
I'm not familiar with these changes.  rdevlin.cronin@, would you happen to know if this was a recent change?
Cc: lazyboy@chromium.org
A few notes here:
- Content verification will require case-sensitivity, so that could be what you're seeing.
- As woxxom@ points out, case sensitivity is actually the spec'd behavior (though I suppose since this is through an extensions API layer, one could argue that the API should transform the URL)
- chrome.tabs.update() shouldn't require web accessible resources at all - web accessible resources are only used for embedding a page in an iframe, importing a script from an external page, etc.

That said, I'd still be interested in knowing what exactly caused this.  I tried a bisect, but as far as I can see, this was the same behavior well before M59.  Are you sure this is a regression seen from just using the chrome.tabs.update() call?
Cc: jmukthavaram@chromium.org
Labels: Needs-Feedback
priyanshurockz@,

Could you please respond as per Comment#6 and update the thread accordingly.

Thanks..!!

Comment 8 by hdodda@chromium.org, Oct 11 2017

Cc: hdodda@chromium.org
Status: WontFix (was: Unconfirmed)
Closing this issue , as there is no update from reporter since long .

Please raise a new issue , if you are facing the issue still in latest chrome channels.

Thanks!

Sign in to add a comment