|Support cookies on file://|
|Reported by f...@gmx.net, Sep 3 2008||Back to list|
Product Version : 0.2.149.27 (1583) URLs (if applicable) : http://www.tiddlywiki.com Other browsers tested: Safari 3: OK Firefox 3: OK IE 7: OK What steps will reproduce the problem? 1. download TiddlyWiki (right-click and save as: http://www.tiddlywiki.com/empty.html) 2. open TiddlyWiki from local file 3. assign username in GettingStarted 4. close TiddlyWiki tab 5. re-open TiddlyWiki What is the expected result? The previously entered username should be filled in automatically. What happens instead? The previously entered username has not have been saved (in a cookie).
Sep 3 2008,
Minimal testcase attached. What is the expected result? Should report "2 cookies found". What happens instead? Reports "no cookies found"
Sep 3 2008,
Chrome intentionally disables cookies on file://, for a variety of reasons. When we wrote our cookie support, the correct behavior was unclear when dealing with things like file shares. We found cookies on file:// to be fairly uncommon, and it has a few negative security implications. You can, however, enable them with the command line flag --enable-file-cookies. I will change this to a feature request for supporting file:// cookies.
Sep 6 2008,
Dean, is there a reason why we'd want this feature request if we've intentionally disabled them?
Sep 6 2008,
OK, marking as WontFix. People can still comment on the bug if they feel it's important, and we can always revisit later on.
Sep 6 2008,
All of the resources at my site http://www.giffmex.org are in TiddlyWiki format. I also use TiddlyWikis for daily productivity and note-taking. As do many, many people. Everyone is pretty excited about Chrome, and would like to see TiddlyWiki work on Chrome. But if you mark it as WontFix, all of us TiddlyWiki users will have to stick with Firefox. Sorry. Dave Gifford
Sep 6 2008,
Cookies are *strictly* a HTTP mechanism as per RFC 2109. There should be no reasonable expectation for them to work for protocols other than HTTP, much less file:///, and it is not clear what their behavior should be, and what rules of security compartmentalization should apply. Some example questions: should cookies for file:///c:/foo/ be shared with file:///c:/bar/? what about cookies for file://otherhost/baz? should cookies from ftp://example.com be shared with http://example.com? what about HTML files downloaded to local disk from the Internet, should they keep their original context, or intrude that of any HTML code installed locally? Lacking clear and consciously defined rules, this is a ticking time bomb. Historically, various browsers followed somewhat inconsistent rules in this department, mostly out of oversight. Most of these mechanisms have undesirable security consequences, too. A very small fraction of applications took the availability of file:// or ftp:// or SMB/NFS cookies for granted and started to rely on this undocumented mechanism for unusual applications. I would be willing to pretty strongly assert that this is a failing on the side of the application, not a particular browser.
Sep 7 2008,
There's an emergent class of applications, which includes TiddlyWiki, Desktop widgets and HTML Applications (HTAs) for which storing cookies for a file URI is extremely useful for maintaining context, such as the wiki author and preferences, across browser sessions. Whilst I'm impressed the development team are cautions in opening up "undocumented" features which have a security impact, Chrome is currently the only major browser not supporting cookies for file URIs, rendering it unusable for a number of existing, often innovative, web applications. This is a shame, because it looks very promising, and would otherwise be a browser I'd advocate people to switch to. Restricting the scope of a stored cookies to the single file URI which created them, is perfectly acceptable for the TiddlyWiki usecase, and a simply implemented rule. In addition, most browsers issue a challenge when opening a file URI for the first time, warning the user using language similar to downloading an application.
Sep 7 2008,
Paul, As I had previous stated, for the people who really do want cookies on file:// protocols, you can run Chromium with the --enable-file-cookies command line flag.
Sep 7 2008,
Sep 7 2008,
> for the people who really do want cookies on file:// protocols, > you can run Chromium with the --enable-file-cookies command line flag Would it not make sense then to turn this into a setting accessible via the UI? The "Under the Hood" options tab seems like the perfect place.
Sep 7 2008,
This is something that a very very small percent of users will want. In fact, I do not encourage this at all, because we intentionally don't allow cookies on file:// over security concerns. I would not want this as a preference as it allows the user to make their browser less secure. If you want to modify your source and build your own Chromium, or to run with a non-recommended command line flag, then you're surfing at your own risk.
Sep 8 2008,
Restricting cookies to a specific file or path doesn't address the security concern because it creates a finer-grained origin (see <http://www.adambarth.com/papers/2008/jackson-barth-b.pdf>).
Sep 19 2008,
I won't use Chromium (as I do nowadays) if I can't use TiddlyWiki!
Nov 3 2008,
Dec 20 2008,
I wont use Chrome if I cant use Tiddlywiki ALSO
Jan 19 2009,
By not allowing local file:/// cookies, you are preventing all current web applications that are used offline from saving/persisting user-data. Local cookie storage is the universally accepted method (as in all other browsers) for saving user data, and is a cross-browser solution. Security is not the issue here, as any offline web-application can store and retrieve information via an online server. So, the only reason i can see, is that this is to promote google gears only - I really hope this is not the case, as Chrome is a fantastic browser. Please support current web-applications, by allowing local cookies - it's essential for them to be able to store user settings etc.
Feb 10 2009,
Feb 25 2009,
Safari allows access only to local cookies which were recorded in the same folder or in the parent folders. Parent folders can't access cookies, stored in child folders firefox uses the same behavior. It seems good behavior, at least all browsers use this defacto
Mar 6 2009,
A shame TiddlyWiki doesn't work properly under Google Chrome when it does under every other.
Apr 23 2009,
I hate to point out the obvious, but the eggheads at Google apparently have never developed web pages of their own offline before uploading them to a server. Testing before going live is, as we all know, generally a good thing. How are millions of web developers around the world supposed to test their new cookie-utilizing web apps (developed offline) against Google Chrome... except once they have gone live? They can test their new creations offline with basically all other browsers... just not Chrome. Writers of Chrome -- did you test the Chrome browser internally before you released it? What if you hadn't? See my point? The responses I am seeing from chromium.org appear to be a cop-out... the other major browsers work just fine offline, without the perceived problems outlined above. I can code a web page, test it (including the cookie aspects) and then upload it to my server with the full confidence that it will work online if it works offline. But... not with Chrome.
Apr 27 2009,
Apr 27 2009,
As discussed earlier, for local development, cookies in file:// might be enabled from command line with --enable-file-cookies.
Apr 28 2009,
Thank you lcamtuf, we are aware of that, but that's kind of like saying "In order to view this new house I built for you, we need to come in through the chimney as there is no front door yet". I don't know about most developers, but when I test a web page in a browser I double- click on its HTML file. I don't start messing around with command lines and then manually typing the address of the test page into the address bar or navigating various levels of directories to locate the page. It is and always has been a basic, fundamental feature of any browser that you could open up a web page on your local machine with full HTML functionality by simply double-clicking it, just like any other file. But not with Chrome. This is am important feature that should be selectable on a permanent basis from a menu in the browser. All the work has been done! The browser can do it! All we are asking for is an easy way to set it up permanently. It seems to me like Google is trying to be a "nanny company" here, kind of like AOL, "protecting" its innocent users from the evils of "dangerous things"! AOL: "Don't click on hyperlinks... they might contain a virus... we'll disable them in emails for you." Google: "Cookies are very dangerous for your health. We don't think you should use them unless you are an expert who knows all about command lines."
May 16 2009,
In the absence of a reasonable response to this issue, can you recommend some other way of storing, say, a language preference, for an offline/online app that does not use Gears? As soon as the user downloads my HTML/JS to local disk, there is no more Spanish or Italian translation because it can't read or store two characters in document.cookie. Everything else works well, and it is ONLY Chrome that fails. Please tell us (the "small percentage of users") how to save and read the tidbits that normally belong in cookies when our users are out of Internet contact.
Jul 21 2009,
Please can anyone help me. I now have Google Chrome and love it. I am a Realtor and use it for property searches. Whenever I enter a multiple listing number to view the homes media/pictures i get pop up blocked. Most of the ones I have used in the past allow me to turn off the blocker for this site but cannot find it for the Chrome. My Realtracs support tells me that for this reason I cannot use Chrome. (I need to allow pop ups for this site) I love Chrome in so many ways and am devistated to leave it. Is there another way? Realtor Boyd
Jul 27 2009,
Aug 27 2009,
Sep 21 2009,
Sep 24 2009,
ARGHHH: two hours wasted trying to figure this out. I understand the rationale but the statement "only a small percentage of applications would want this" is way off the mark!
Oct 2 2009,
@diagnose - "I don't know about most developers, but when I test a web page in a browser I double-click on its HTML file." If you are creating web sites with HTML only, you are in the minority. Most web developers are using some kind of server-side processing (PHP, Rails, Django, ASP.NET) so that the site can use a database, or, at the very least, not repeat menu code in every file (for example, see this tutorial on PHP's include command - http://www.tizag.com/phpT/include.php). In that case, we run a web server on our local machine for testing purposes. The address of the page would then start with http://localhost instead of file://. @everyone else: does opening the page from http://localhost solve the problem?
Oct 2 2009,
> does opening the page from http://localhost solve the problem? While I haven't tested this, I assume it would - however, the requirement to have a local web server (for HTTP) is contrary to TiddlyWiki's self-contained single-file paradigm. FWIW, Firefox supports file://localhost/path/to/local/file: http://tiddlywiki.org/wiki/Firefox#Cookies
Dec 18 2009,
In order to be able to use local cookies, I've been starting Chrome with --enable-file- cookies in the command line. Awkward, and annoying, but it has worked. However, lately even that doesn't work. Has Chrome changed its policy, or does this indicate a problem on my machine in particular?
Dec 18 2009,
Works for me in 4.0.266.0; if it stopped working for you in some particular version, sounds like a bug.
Dec 20 2009,
The version I'm using under XP, in which the flag doesn't work, is 188.8.131.52, which "About Google Chrome" says is up to date.
Dec 25 2009,
I'm on ubuntu and using Chromium 4.0.281.0 (35262). The command --enable-file-cookies does not work for me too. TiddlyWiki would not save when opened in chromium.
Dec 28 2009,
Not working for me in Chrome version 184.108.40.206 on Vista. Started Chrome with -- enable-file-cookies but cookies are not being set when testing my page locally.
Jan 8 2010,
Still --enable-file-cookies not working in Chrome 220.127.116.11 (Linux).
Jan 18 2010,
--enable-file-cookies not working in Chrome 18.104.22.168 (Windows 7).
Jan 22 2010,
... --enable-file-cookies works in Chrome 22.214.171.124, Windows 7!
Jan 22 2010,
--enable-file-cookies not working in Chrome 4.0.295.0 (Windows 7)
Jan 23 2010,
--enable-file-cookies is not working in Chrome 126.96.36.199 on Windows XP pro 5.1
Jan 26 2010,
--enable-filecookies is not working in Chrome 188.8.131.52 (36714) on Windows XP pro 5.1
Jan 26 2010,
Just saw issue 17790 . Thought20 commented "If there are NO OTHER CHROME INSTANCES running on the machine, starting Chrome with --enable-file-cookies works. If there are any instances already running that were NOT started with --enable-file-cookies, any launch of a new Chrome instance will ignore this flag." Ah hah. Retested and --enable-file-cookies works in Chrome 184.108.40.206 (36714) on Windows XP pro 5.1
Jan 26 2010,
--enable-file-cookies not working in Chrome 4.0.302.3 (Windows 7)
Jan 27 2010,
As commentor #45 cynthia.rayl/Thought20 pointed out this appears to be the case for Chrome 4.0.302.3 on Win 7. If you've setup an application shortcut and have that open first --enable-file-cookies will not work. I believe you can add the --enable-file- cookies to all your Chrome application shortcuts and you should be fine. But this work around is stupid. I rely heavily on tiddlywiki. Please allow file cookies on Chrome Google!
Mar 8 2010,
This issue is also discussed at http://www.google.com/support/forum/p/Chrome/thread?tid=23fd2349855c0f17&hl=en&fid=23fd2349855c0f170004815132b3ad73 And I just posted this comment there. A strange thing happened yesterday in that I thought about how Google Chrome won't use local cookies and then two posts were made to the thread. I decided to try it again (it did not work for me last April when I tried) since more people have said that adding <<--enable-file-cookies>> into the command line does work. Chrome requires one other change -- in the cookie options one must select <<Allow all cookies>> rather than <<Accept cookies only from sites I visit>>. Apparently a local file is not considered a "site that I visit". So, either I have keep switching back and forth or always accept third party cookies. Incidentally, Chrome reports 'cookie written' even when it does not rather than report a failure to write a cookie. Obviously, Google is infected with the NIH virus. <sigh> I will also add that the command line thing can be put into the shortcut so that it is automatic.
Mar 12 2010,
Hi, as a developer I have to note it is better to restrict users in a small way (it's not that hard to set the --enable-file-cookies flag to your shortcuts and default double-click open functionality) than to making then vulnerable to cross site scripting. I do however do not like that you do not get any notification of this. I therefore would like to suggest this change request: When a file wants to store cookies when it has no permissions (file:///) to present the user with a pop-up with an explanation of why it will not work and how to work around it (including the risks).
Apr 15 2010,
Apr 18 2010,
has anyone tried using HTML5 features to work around this? webstorage might work. i was also thinking of storing this in the #hash tag, however that is really limiting and hard to carry over from page to page. what other ways are there to store info in a browser durring a session? flash cookies? whenever a browser has unexpected behavior like this, i feel like there is always a work around that comes about.
May 27 2010,
@google - please link me to an html document that i can save to my desktop and run in IE and/or FF compromising my machine with file:// cookies. until you can either provide an example of a security hole or implement file:// cookies the way FF and IE do then my chrome browser will continue to gather dust. (what was that about google being open and inclusive unlike apple?)
May 28 2010,
Jun 30 2010,
I am one of the developers of the C++ source code documentatiob tool DoxyS (http://www.doxys.dk) which generates HTML code intended very much for local viewing too. We also have problem with Chrome :-(
Jul 4 2010,
I haven't tested this, but if there's a one-file webapp on linux, #!/bin/bash while true; do nc -l 49152 < "$1:-/dev/null"; done & google-chrome http://localhost:49152/ can be saved in an executable text file drag files into it to execute Put a pair of brackets around the loop and an ampersand after to keep it alive even after chrome exits If multi-file support is necessary, you can write a script that uses nc to only listen to localhost, and uses sed to parse the header, although you may as well: mount ~/web-testing /var/www/html/testing -o bind And disable selinux Windows: you can install cygwin (first suggestion), or apache (second) fine print: DISCLAIMER: I have tested none of this. If you follow any of these instructions, you may become vulnerable to velociraptor attacks and other nasty things.
Aug 12 2010,
firstname.lastname@example.org wrote: This is something that a very very small percent of users will want. In fact, I do not encourage this at all, because we intentionally don't allow cookies on file:// over security concerns. I would not want this as a preference as it allows the user to make their browser less secure. If you want to modify your source and build your own Chromium, or to run with a non-recommended command line flag, then you're surfing at your own risk. --- Then add this function in "Options" menu (like pop-up that are disabled by default) with "suggested" choice enabled, and give to the user the possibility to change it.
Aug 12 2010,
deanm wrote "I would not want this as a preference as it allows the user to make their browser less secure." So probably you can stop hoping to get this as a user option. Instead look at HTML5 offline functionality and bind your stored data to a website hostname. The local helpfile.htm use case seems it's getting thrown out completely though.
Aug 27 2010,
I've problem with some app intended for local use only, where pages must know some data from pages previously visited. Why Chrome sets itself as default application for opening HTML files at all if it makes HTML application not functional? Maybe denying users at all to open HTML files without a webserver will be better? At least it won't make users confused why app that should work does not.
Sep 12 2010,
There is a striking resemblance here with this issue: http://code.google.com/p/chromium/issues/detail?id=47416
Sep 18 2010,
It's crazy that this isn't enabled by default. On OSX, it's a bit more challenging to add a command line switch to an app. Here's the best writeup I've found: http://kfalck.net/2010/05/25/how-to-enable-chrome-web-store-applications-on-mac-os-x (substitute the command line switch described for --enable-file-cookies of course) There's no way I'd walk a novice through this. For the novice's I know, I could just send them an updated app. To the security argument: restricting cookies to the full URI (including the file name) should negate any of the security issues and allow most, if not all of the mentioned apps to function properly.
Sep 18 2010,
Who uses Chrome on MacOSX where there are already native Safari webbrowser which uses same rendering engine (WebKit)?
Sep 29 2010,
I too feel this is ridiculous! I develop many things locally and have been banging my head until I read this thread! It should be an option I can enable. How is that making Chrome unsecure, if I know the risks involved. Seems to me you are cutting off your nose to spite your face!
Oct 5 2010,
I just downloaded Google Chrome to see what my website looks like on it, not knowing that the JS and Jquery would not work locally on my computer. I'm not bothered about all the reasons for this and I am not even going to try to fix it. So I am now going to discard and forget all about Google Chrome. Thank heaven for Firefox.
Oct 7 2010,
thank heaven for firefox indeed, it took me a couple of hours to figure out that chrome wasn't saving local cookies... quite annoying that there was absolutely no notification or errors in the JS console when trying to set a cookie through JS. you can make the argument that cookies are an HTTP protocol spec - and I would say that chrome should disable cookies in JS completely then, because that's not coming through the HTTP headers... I think it's silly that at the very least there is no notification that local cookies are not being stored, or that there is no easy configuration switch to enable this functionality... you are forced to use a command line switch....
Mar 10 2011,
Status : Wontfix Does any one at Google has some idea, about time that a small developer wastes because their browser does not behave like most other browsers on the issue. and then we condemn Microsoft for being insensitive to public requests. Google is a quick learner indeed.
Mar 10 2011,
I just tell my clients they must use Firefox, and avoid Chrome and IE. Problem solved, I guess?
Mar 10 2011,
It seems to me that Firefox has also stopped supporting cookies on file:// -- or is it just me? What a lame reason by Google techs here: "Security Reasons". LOL! Protect myself from myself?
Mar 18 2011,
Jul 18 2011,
Jul 18 2011,
This was a major frustration to me too. The answer for me was to use HTML5's Local Storage . I was only using cookies to retain (client side) user configuration on whether components on my pages were 'on' or 'off'. Therefore Local Storage was a perfect alternative to me for cookies. Hope this helps.  http://paperkilledrock.com/2010/05/html5-localstorage-part-one/ http://diveintohtml5.org/storage.html
Jul 31 2011,
Aug 2 2011,
I use Chrome like I used the last version of Netscape - simply as a nice clean fast webmail client for GoogleMail and Yahoo, with nothing in bookmarks. I just don't use it for browsing the web. I tell everyone I know, or web design for, to use Opera or FireFox; not to be surprised if Chrome behaves oddly, and to strenuously avoid IE.
Aug 24 2011,
3 years and still "Wont Fix". This is ridiculous. As some fellows here I have wasted valuable time on this bugger. Time I don't get paid for... I would except that kind of behaviour from IE. That's one reason why test my designs in IE from a dropbox public folder. I have to do that too in chrome now. Pity. If you really can't fix this, at least bother to give SOMEWHERE some FEEDBACK. use a popup, or let the Chrome developer tools shed some light on the root of this problem. Regards, pepebe
Sep 6 2011,
Dean - you wrote this in No 5 above about 3 years ago: Comment 5 by de...@chromium.org, Sep 6, 2008 OK, marking as WontFix. People can still comment on the bug if they feel it's important, and we can always revisit later on. Status: WontFix - I wrote this in comment 63 about 1 year ago: Comment 63 by john.gu...@yahoo.co.nz, Oct 4, 2010 I just downloaded Google Chrome to see what my website looks like on it, not knowing that the JS and Jquery would not work locally on my computer. I'm not bothered about all the reasons for this and I am not even going to try to fix it. So I am now going to discard and forget all about Google Chrome. Thank heaven for Firefox. - WEll I just had a look at Chrome again, and I suggest you FIX IT. I just dumped Chrome again because of no JS on local host. And I am not going to try to fix it. But it woud be nice if you could explain to us all who have bothered to contact youe, why on earth it cannot be done. I really would like to test my Jquery stuff at home on my little website - but Google - he say No!! See you next year... Cheers John Guise
Sep 7 2011,
Hey guys, since it appears all comments here are missed by the development team, I created a new issue in hopes they at least add a warning for this issue: http://code.google.com/p/chromium/issues/detail?id=95644 Perhaps you can add your support to this issue, so when it gets picked up, the gravity of the issue is directly clear.
Sep 7 2011,
Dec 9 2011,
I want Tiddly Wiki!
Mar 12 2012,
THIS is what you have to do to enable local cookies for debugging on Mac OS X??? http://kfalck.net/2010/05/25/how-to-enable-chrome-web-store-applications-on-mac-os-x It's the only solution I've located after tons of searching. From the 'geniuses' at Google, this is s super 'retarded' solution! Think. Harder. The app has about:flags to enable crazy features - put a damn 'enable local cookies' flag there if you cannot behave like ALL the other browsers do.
Mar 27 2012,
use 127.0.0.1 instead of localhost and it works ;-)
Mar 27 2012,
@81: http://127.0.0.1/ OR http://localhost/ work if you're running a local web server. That's not the point. The problem is that Chrome blocks cookies and doesn't even show a message in the log when you load something via file:// (For example, A TiddlyWiki file, which needs to be run from file:// to be editable)
May 31 2012,
Just discovered this issue. For me, the inability to check a setting to enable file cookies just ruined Chrome as a viable browser option. 90% of my web productivity is focused around TiddlyWikis, and losing options every time I close Chrome is simply unacceptable. Currently, I'm going back to attempt to correct FireFox's stability issues rather than fight with Chrome over a simple option that people have been asking for for years. When a browser breaks my goto productivity HTML file, I lose patience with the browser.
Jun 1 2012,
Again I want to remind everyone that this issue is closed, so please also comment and star the following issue, perhaps they will have a look at it some time: http://code.google.com/p/chromium/issues/detail?id=95644
Aug 27 2012,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=153484 ------------------------------------------------------------------------ r153484 | email@example.com | 2012-08-27T15:04:14.465102Z Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/content_settings/content_settings_browsertest.cc?r1=153484&r2=153483&pathrev=153484 M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/test/browser_test_utils.cc?r1=153484&r2=153483&pathrev=153484 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/fast_shutdown_browsertest.cc?r1=153484&r2=153483&pathrev=153484 M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/test/browser_test_utils.h?r1=153484&r2=153483&pathrev=153484 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/functional/PYAUTO_TESTS?r1=153484&r2=153483&pathrev=153484 D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/functional/cookies.py?r1=153484&r2=153483&pathrev=153484 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/resource_dispatcher_host_browsertest.cc?r1=153484&r2=153483&pathrev=153484 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/cookie_policy_browsertest.cc?r1=153484&r2=153483&pathrev=153484 Rewrite the cookies pyauto test as browser tests. I didn't port testCookiesFile since cookies aren't supposed to work on file urls by default (see crbug.com/535 ). I removed all the duplicate code for getting cookies in browser tests and moved them to browser_test_utils.h. BUG= 143637 Review URL: https://chromiumcodereview.appspot.com/10875045 ------------------------------------------------------------------------
Oct 13 2012,
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Jun 27 2013,
Issue 254688 has been merged into this issue.
Apr 24 2017,
The following revision refers to this bug: https://chromium.googlesource.com/external/gyp/+/a94b02ec68fb7fac617032b59c1705079ffd0dd7 commit a94b02ec68fb7fac617032b59c1705079ffd0dd7 Author: Dirk Pranke <firstname.lastname@example.org> Date: Mon Apr 24 18:31:18 2017 Disable a bunch of tests on Mac. It looks like the xcode-ninja generator is at least partially broken on 10.12/Xcode8.2, plus a few other tests are failing. I've filed bugs for each failure. I've also fixed a couple of failures where it looks like the output from various mac tools has changed slightly. Remail@example.com, firstname.lastname@example.org BUG= 527 , 529 , 530 , 531 , 532 , 533 , 534 , 535 Change-Id: I59269afa860b4068173c00fced85154805a7f432 Reviewed-on: https://chromium-review.googlesource.com/479437 Reviewed-by: Nico Weber <email@example.com> Reviewed-by: Dirk Pranke <firstname.lastname@example.org> Commit-Queue: Dirk Pranke <email@example.com> [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/mac/gyptest-clang-cxx-library.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/mac/gyptest-lto.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/ios/xctests/gyptest-xctests.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/mac/gyptest-deployment-target.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/ios/gyptest-extension.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/mac/gyptest-xctest.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/ios/gyptest-archs.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/gyptest.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/ios/gyptest-app-ios.py [modify] https://crrev.com/a94b02ec68fb7fac617032b59c1705079ffd0dd7/test/mac/gyptest-libraries.py
|► Sign in to add a comment|