A URL object's origin property should return "null" when its scheme is "file" or other unlisted schemes
Reported by
l446240525@gmail.com,
May 3 2016
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2715.0 Safari/537.36 Steps to reproduce the problem: 1. see URL spec 4.5 https://url.spec.whatwg.org/#origin: > "file" > Unfortunate as it is, this is left as an exercise to the reader. When in doubt, return a new opaque origin. > > Otherwise > Return a new opaque origin. 2. then see HTML spec 7.5 https://html.spec.whatwg.org/multipage/browsers.html#unicode-serialisation-of-an-origin > 1. If origin is an opaque origin, then return "null". What is the expected behavior? What went wrong? see attachments Did this work before? N/A Chrome version: 52.0.2715.0 Channel: n/a OS Version: OS X 10.10.4 Flash Version: Shockwave Flash 21.0 r0
,
May 3 2016
This behavior is same from M 33.0.1701.0 and prior to it displayed undefined. So marking this as a non regression issue and untriaged.
,
May 3 2016
,
May 6 2016
,
May 13 2016
,
Jun 1 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 11 2016
This issue has been moved once and is lower than Pri-1. Removing the milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 18 2016
,
Aug 22 2016
It's returning SecurityOrigin::toString(). For "file", it returns "null" only when m_blockLocalAccessFromLocalOrigin is true. It's false by default. For others not listed there, shouldTreatAsUniqueOrigin() could be fixed to create a SecurityOrigin representing the unique origin, but needs to be careful not to regress extensions.
,
Dec 16 2016
,
May 16 2017
Issue 722089 has been merged into this issue.
,
Nov 10 2017
,
Feb 18 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by karandeepb@chromium.org
, May 3 2016