cannot access cross access files in framesets when files saved in html format
Reported by
rathanre...@gmail.com,
Aug 17 2017
|
|||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
Steps to reproduce the problem:
1. files saved in my D drive in .html format.
2. when i tried to access one frame value from the other frame in framesets.
3. chrome could not access the files,where the same files got executed in other browsers. tried to google it but i could not get the solution.
What is the expected behavior?
when the input value in one frame is tried to access from other frame in framesets when especially saved in .html format i could not access them.
Uncaught DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.
at myFunction (file:///D:/Training%20tasks/html%20css%20&%20js/framesets/framescript.js:7:31)
at HTMLInputElement.onkeyup (file:///D:/Training%20tasks/html%20css%20&%20js/framesets/test.html:13:74)
What went wrong?
there might be a problem to access the files of frameset when especially saved in .html if the access is granted then we can resolve the issue.
i can clearly state that the issue is with chrome as the files got executed in other browsers in .html format
when the saved files are saved in .php format and run through localhost in chrome files got executed.
so please review the error code when the files saved in html format
Did this work before? No
Chrome version: 60.0.3112.90 Channel: n/a
OS Version: 6.3
Flash Version:
i discussed the same issue in chromium discussions but i did not get any response. please review the following files and you can better knowledge of the error in the chrome
,
Aug 24 2017
Able to reproduce the issue on windows 7 , Mac os 10.12.6 and ubuntu 14.04 using chrome M60 #60.0.3112.101 and M62 #62.0.3194.0 . This is seen from M45 and hence non-regression issue. Hence marking it as untraiged for further inputs on this. Thanks!
,
Oct 5 2017
we consider file:// URLs to be unique origins, so this is WAI
,
Oct 5 2017
can you please give a clear explanation on this issue, as i am unable to understand the issue with the chrome regarding this particular issue where i could not access the files only on chrome where the same can be executed on all the other browsers.
,
Oct 5 2017
you kept the status as 'WontFix' what this particularly mean..? does you browser does not support or else you people are not capable to fix that bug..?
,
Oct 5 2017
It means that we don't consider the behavior to be a bug. Different browsers have made different decisions about the security properties of `file:` URLs. Chrome is fairly conservative in order to prevent data leakage (consider a downloaded file which read `/etc/passwords` or skimmed through your downloads folder). I agree with your underlying claim that browser should agree on this kind of thing. I'll see if I can get other vendors on board with Chrome's behavior.
,
Oct 6 2017
it seems you doon't consider that as a bug. what do you consider that to be..? if this was made to prevent the data leakage then i think no web pages run on the html files and if at all we try to run our web pages on .html then this browser to be the one we should not use for such type of files. if other browsers are allowing to run such type of files then those browsers such as microsoft edge and internet explorer allow the leakage of our data through these files. but according to me i consider that issue to be a bug in a great browser such as chrome, if you cannot provide alternate way for your users.
,
Oct 6 2017
> it seems you doon't consider that as a bug. what do you consider that to be..? I agree that this should be closed as WontFix. We don't consider it a bug that one `file:` can't access another. That's the behavior we intentionally put into place. > if other browsers are allowing to run such type of files then those > browsers such as microsoft edge and internet explorer allow the > leakage of our data through these files That's correct. I consider this behavior to be a bug in those browsers. I've filed https://github.com/whatwg/html/issues/3099 against HTML in the hopes of having that conversation with a wider audience. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by tkent@chromium.org
, Aug 17 2017