Anchor `download` attribute is overridden by `target`
Reported by
oliverj...@gmail.com,
Mar 17 2018
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36 Steps to reproduce the problem: 1. Create an anchor element using `download` and `target="_blank"` attributes 2. Click the anchor Example: https://react-ts-a7n6ew.stackblitz.io/ What is the expected behavior? The file is downloaded without opening a new tab, as it did in Chrome v64. What went wrong? The file is downloaded whilst opening a new tab, which is new in Chrome v65. Did this work before? Yes 64 Does this work in other browsers? No Observed behaviour applies to Safari. Not sure if this has always been the case. Expected behaviour applies to Firefox. Chrome version: 65.0.3325.162 Channel: stable OS Version: OS X 10.13.3 Flash Version:
,
Mar 19 2018
,
Mar 19 2018
andrew.glaze76@ Thanks for the issue. Tested this issue on Mac OS 10.12.6, Windows 10 and Ubuntu 14.04 on the latest Canary 67.0.3374.0 and Stable 65.0.3325.162 and able to reproduce the issue by following the steps mentioned above. Bisect Information: =================== Good Build: 65.0.3309.0 (Revision - 526409) Bad Build : 65.0.3310.0 (Revision - 526575) On executing the per-revision bisect script, below is the Changelog URL: https://chromium.googlesource.com/chromium/src/+log/cbce1149c9ae08297b816effbf456c02f97df8db..f2d2fe87028de36a489f7db3f5fb28da2e9d9b2b From the above Changelog, suspecting the below change: Reviewed-on: https://chromium-review.googlesource.com/758236 jochen@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Adding ReleaseBlock-Stable as this is a recent regression. Please feel free to remove it if it is not applicable. Thanks.
,
Mar 19 2018
thx for the report, I'll try to figure out which behavior is closer to the spec.
,
Mar 19 2018
For context, the reason we want to specify `download` and `target` is because `target` is a fallback, so that browsers without support for `download` will open a new tab instead.
,
Mar 20 2018
,
Mar 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/23d031266e4759af1cbf58dfed947fdfcda5fe7d commit 23d031266e4759af1cbf58dfed947fdfcda5fe7d Author: Jochen Eisinger <jochen@chromium.org> Date: Tue Mar 20 18:46:54 2018 Ignore the target attribute if the download attribute is present BUG= 823050 R=mkwst@chromium.org Change-Id: I50a6d1efb605c8eff538a0f157203812d0ba5f1b Reviewed-on: https://chromium-review.googlesource.com/970701 Reviewed-by: Mike West <mkwst@chromium.org> Commit-Queue: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#544449} [modify] https://crrev.com/23d031266e4759af1cbf58dfed947fdfcda5fe7d/content/browser/download/download_browsertest.cc [add] https://crrev.com/23d031266e4759af1cbf58dfed947fdfcda5fe7d/content/test/data/download/download-attribute-with-target.html [modify] https://crrev.com/23d031266e4759af1cbf58dfed947fdfcda5fe7d/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp
,
Mar 20 2018
,
Mar 20 2018
Thanks for fixing this, when we can expect it will land in Chrome stable?
,
Mar 20 2018
right now, the fix is in 67, if canary doesn't explode, i'll request merge to 66, I don't think I'll attempt merging to 65 at this point anymore
,
Mar 21 2018
pretty confident that this one is safe to merge
,
Mar 21 2018
This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 22 2018
Issue 824702 has been merged into this issue.
,
Mar 22 2018
actually, I don't like the fix yet
,
Mar 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2157880210b71ecbda14405893e530bf6711a319 commit 2157880210b71ecbda14405893e530bf6711a319 Author: Jochen Eisinger <jochen@chromium.org> Date: Thu Mar 22 19:06:28 2018 Revert "Ignore the target attribute if the download attribute is present" This reverts commit 23d031266e4759af1cbf58dfed947fdfcda5fe7d. Reason for revert: Heuristic is too simplistic Original change's description: > Ignore the target attribute if the download attribute is present > > BUG= 823050 > R=mkwst@chromium.org > > Change-Id: I50a6d1efb605c8eff538a0f157203812d0ba5f1b > Reviewed-on: https://chromium-review.googlesource.com/970701 > Reviewed-by: Mike West <mkwst@chromium.org> > Commit-Queue: Jochen Eisinger <jochen@chromium.org> > Cr-Commit-Position: refs/heads/master@{#544449} TBR=jochen@chromium.org,mkwst@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 823050 Change-Id: Ib36b4a191b0501de80341be991e55f20c4bd9fb1 Reviewed-on: https://chromium-review.googlesource.com/975553 Reviewed-by: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#545183} [modify] https://crrev.com/2157880210b71ecbda14405893e530bf6711a319/content/browser/download/download_browsertest.cc [delete] https://crrev.com/ec6945d8a05ff28073f9b0bc0da6c0f6cb632048/content/test/data/download/download-attribute-with-target.html [modify] https://crrev.com/2157880210b71ecbda14405893e530bf6711a319/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp
,
Apr 4 2018
,
Apr 6 2018
Issue 829427 has been merged into this issue.
,
Apr 10 2018
fixed in 66 |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by woxxom@gmail.com
, Mar 17 2018