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

Issue 111700 link

Starred by 156 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 24
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-06-22
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Handle conflicts between web request extensions gracefully.

Reported by aocampo@chromium.org, Jan 27 2012

Issue description

Chrome 17 and up

Logging this for tracking purposes.

What steps will reproduce the problem?
1. Install the 2 extensions 
2. Try to navigate to some sites i.e. http://news.yahoo.com/money-managers-good-promise-philanthropy-195951763.html
3.

What is the expected output? What do you see instead?
Under wrench, you'll begin to start a 'Misbehaving extension' warning. 


Please use labels and text to provide additional information.
Dominic mentioned that this is because - 

HTTPS-everywhere tries to redirect http://ad.yieldmanager.com/st?_PVID=1xZ2Yk3us3.Sq5IxTt0PrwPXSn056U7dFPQA... to https://ad.yieldmanager.com/...
while at the same time
AdBlock tries to redirect it to a data:// URL that contains a place holder.
 
Cc: battre@chromium.org
Reproducible on Win7/4 bit - 18.0.1025.1 (Official Build 119930)
Reproducible on Win7/64 bit - 18.0.1025.2 (Official Build 120152)

I installed HTTPS-Everywhere & Cat Block extensions installed.
Misbehaving Extension.png
44.4 KB View Download
I tried, but cannot reproduce this. I need more details.

I used Adblock Plus (Beta) 1.2 from the webstore and HTTPS Everywhere from the git repository git://git.torproject.org/https-everywhere.git

I visited the news.yahoo.com website listed above, slashdot, techcrunch, engadget but could not reproduce the error.

I also tried Adblock Plus (Beta) 1.2 from the webstore with the catblock extension and visited http://icanhascheezburger.com/. No problem either.

The mentioned bug should not occur. We have special logic that allows one extension to redirect to a data:// url (Adblock) and another extension to redirect to a new url. In this case, we consider the redirection to a data:// URL as a cancel event that is given precedence.

If you have a reproducible case, please attach a dump of the netlog (go to chrome://net-internals). You should do this from a freshly started session, as the netlog will contain your browsing history otherwise.
Cc: jhurwich@chromium.org
Status: Invalid
Per battre's comment and without future comment from the filer, I'm going to close this as invalid.  aocampo, address Comment #4 and reopen this issue if you are still experiencing this problem.
This issue looks fixed using the updated versions of the 2 extensions. 

Comment 8 Deleted

Comment 9 by Deleted ...@, Feb 29 2012

not fixed i'm afraid.
Win7x64
Chrome 17.0.963.56 m
Adblock+ beta 1.2
HTTPSe 2012.2.27

"Warning:
This extension failed to modify a network request because the modification conflicted with another extension."

i think this may have something to do with the "adversity" and "antisocial" filter lists - http://adversity.uk.to/
If you can reproduce this, please
- Close all tabs
- Restart chrome
- Reproduce the problem
- Go to chrome://net-internals/ and dump the network traffic
- Attach the traffic to this bug

That would help me tremendously in figuring out what is going on. Please note, that the data dump may contain personal information depending on which pages / extensions are opened. Feel free to send me the dump to battre@chromium.org if you feel better about this.

Thanks.
Dump attached.

Installed 'Adblock Plus (Beta) 1.2' and 'HTTPS Everywhere 2012.2.27'; Navigated to www.yahoo.com; observed warning message "This extension failed to modify a network request because the modification conflicted with another extension." on both extensions.
a75327b5-d11d-4edb-8efd-9cfdf66bbb9a
690 KB View Download
Cc: mkwst@chromium.org
Owner: battre@chromium.org
Status: Assigned
Thanks. The culprit is in redirection:

(P) t=1331333859289 [st= 0] +REQUEST_ALIVE                       [dt=94]
(P) t=1331333859290 [st= 1]    +URL_REQUEST_BLOCKED_ON_DELEGATE  [dt= 5]
(P) t=1331333859295 [st= 6]        CHROME_EXTENSION_REDIRECTED_REQUEST  
                                   --> extension_id = "mlomiejdfkolichcflejclcbmpeaniij"
(P) t=1331333859295 [st= 6]        CHROME_EXTENSION_IGNORED_DUE_TO_CONFLICT  
                                   --> extension_id = "cfhdojbkjhnklbpkdaibdccddilifddb"
(P) t=1331333859295 [st= 6]    -URL_REQUEST_BLOCKED_ON_DELEGATE  
(P) t=1331333859295 [st= 6]     URL_REQUEST_START_JOB            [dt=88]
                                --> load_flags = 65536 (VERIFY_EV_CERT)
                                --> method = "GET"             
                                --> priority = 3               
                                --> url = "http://bs.serving-sys.com/BurstingPipe/adServer.bs?cn=tf&c=19&mc=imp&pli=3847576&PluID=0&ord=1331333855&rtu=-1"
(P) t=1331333859383 [st=94]     URL_REQUEST_START_JOB            [dt= 0]
                                --> load_flags = 65536 (VERIFY_EV_CERT)
                                --> method = "GET"             
                                --> priority = 3               
                                --> url = "data:image/gif;base64,R0lGODlhAQABAPAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="
(P) t=1331333859383 [st=94] -REQUEST_ALIVE

This is actually a conflict between Adblock Plus and Ghostery. They both want to redirect the request to a transparent image - but to different ones. In this case, it would help if they both agreed on the same data:-URL.

data:image/gif;base64,R0lGODlhAQABAPAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw== is the transparent image by Ghostery.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAACklEQVR4nGMAAQAABQABDQottAAAAABJRU5ErkJggg== is the transparent image by AdBlock Plus.

If both extensions redirect to different targets, I don't see a way that Chrome would not consider this a conflict.
What about http://code.google.com/chrome/extensions/webRequest.html :

"Conflict resolution
"In the current implementation of the web request API, a request is considered as cancelled if at least one extension instructs to cancel the request. If an extension cancels a request, all extensions are notified by an onErrorOccurred event. Only one extension is allowed to redirect a request or modify a header at a time. If more than one extension attempts to modify the request, the most recently installed extension wins and all others are ignored. An extension is not notified if its instruction to modify or redirect has been ignored.

Why not follow what the docs say?

By the way, "misbehaving extension" is bad user-facing messaging. It makes it seem like the involved extension is doing something bad. This leads to uninstalls.
I am able to reproduce the bug with just Ghostery and HTTPS Everywhere installed. Dump attached, although I think we now know what the issue is.

The conflict resolution in Comment 13 appears to be working as expected. Ghostery is the most recently installed extension (it was updated on 8th March) so its modifications take precedence and the other extensions throw up the errors.
a768ec78-da9b-43bd-ac5f-3c88ce99dd92
300 KB View Download
Cc: mpcomplete@chromium.org
I am not sure about silently ignoring conflicts without warning the user. After all the redirections may be privacy and/or security relevant. I am happy to discuss alternatives, though. We could 
- provide a string constant in the API that represents a transparent pixel, or 
- modify cancel so that it redirects to transparent pixels for type==="image", to empty HTML documents for type==="main_frame"/"sub_frame", etc.
- provide a "cancel and redirect" operation that is less strict about generating warnings (not sure whether I like this approach).

I agree that the "misbehaving extension" is a bad messaging and will work on changing that. Due to string approval and translation, this takes quite some time, however (this can probably go only into the next beta).

In the mean time, I suggest that you try to agree with other extension authors on how to represent a transparent pixel. They should all look alike. :-) It should not take much effort and can be released instantly.

Comment 16 by sve...@gmail.com, Mar 11 2012

I have the same conflict with Adblock Plus (Beta) and Ghostery.

Comment 17 by Deleted ...@, Mar 12 2012

Same error with Chrome 17.0.963.78 m on win7x64 Version 6.1.7601 with HTTPS Everywhere 2012.2.27 and AD Block Plus Beta 1.2
If you have a way of reproducing the conflict of HTTPS Everywhere and AdBlock Plus, I'd be still interested in a network dump that shows this. (No additional reports of AdBlock vs. Ghostery necessary).

If you feel comfortable using the command line, an even more reliable way of recording the network traffic than what reported in comment #10 is to start chrome with a command line parameter --log-net-log=filename.
Cc: vandanashah@chromium.org jayakrishnat@chromium.org arsids@chromium.org gailh@chromium.org srihariraju@chromium.org
Labels: GoogleFeedback
The below data is provided based on user reports in 'GoogleFeedback'. We are unable to reproduce this issue.

5 users have reported this issue in 'GoogleFeeback' since 03/01/2012 

Chrome Version       : 17.0.963.79 / 19.0.1067.0 

For more details, refer the user reports below:
http://goto.google.com/212637418
http://goto.google.com/212418293
http://goto.google.com/210113478

For further more user reports, refer the below cluster URL
http://goto.google.com/2830634
Project Member

Comment 20 by bugdroid1@chromium.org, Mar 20 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=127663

------------------------------------------------------------------------
r127663 | battre@chromium.org | Tue Mar 20 03:11:40 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/generated_resources.grd?r1=127663&r2=127662&pathrev=127663

Replace string 'Misbehaving extension' with 'Extension error' in context of the webRequest API

The string 'Misbehaving extension' indicated that the extension author did
something wrong, even though the problem might be related to a conflicting
modification of two webRequest API extensions. It is neither extension's fault,
they are just incompatible.

BUG= 111700 
TEST=no

Review URL: https://chromiumcodereview.appspot.com/9664060
------------------------------------------------------------------------
Re: Comment 18. I have stumbled across a way of reproducing the conflict (although I suppose it may be a different conflict) with just HTTPS Everywhere and Adblock Plus  active while navigating to www.gumtree.com. 

This has been the only website where I have observed the conflict. 

Dump attached using the method in comment 18.
560936fa-7d55-4d80-8273-668ddc09d4eb
859 KB View Download
Thanks, this is helpful. In this case the URL causing trouble is an iframe.

HTTPS Everywhere redirects to an https scheme, while AdBlock redirects to about:blank.

I gave priority to data:// URLs so that they are not considered to conflict with redirects to different web resources. I did not cover about:// URLs in that change, though.

As AdBlock Plus has a shorter possible release cycle, it would be sufficient to replace the redirect to "about://blank" to "data:text/html,"
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 27 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=129117

------------------------------------------------------------------------
r129117 | battre@chromium.org | Mon Mar 26 20:07:30 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/api/web_request/web_request_api_unittest.cc?r1=129117&r2=129116&pathrev=129117
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/api/web_request/web_request_api_helpers.cc?r1=129117&r2=129116&pathrev=129117

Consider redirects to about:blank as canceling and don't flag conflicts

If one extension redirects a webrequest to a different URL (e.g. from http://foo.com to https://foo.com) and another extension redirects to about:blank, the latter wants to express that it intends to cancel the request. With this CL we give precedence to cancelling requests by redirecting to about:blank and don't flag them redirect conflicts.


BUG= 111700 
TEST=no


Review URL: http://codereview.chromium.org/9857009
------------------------------------------------------------------------
I see the last update for this thread was in March. Anything new on the development front. I see this same error with Ghostery now. I have adblock plus and HTTPS everywhere also installed.

Thanks.
The status is the following: If the error messages appear, the extensions seem be simply incompatible. I have a changelist in flight that gives more details, where the conflict occurred, but it won't resolve the conflicts themselves.

The declarative WebRequest API will have methods "redirectToTransparentImage" and "redirectToEmptyDocument" to make sure that extensions use the same data:// URLs for this purpose. On a short term, only the extension authors can try to agree on common behavior to reduce the conflicts. chrome://net-internals lists all network traffic and shows which requests had conflicts. Search for CHROME_EXTENSION_IGNORED_DUE_TO_CONFLICT.
Project Member

Comment 26 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Feature-Extensions Cr-Internals Cr-Platform-Extensions

Comment 27 by k...@kbit.dk, Jul 30 2014

Blocking: kbsslenforcer:107
Ping? Is this issue fixed or does it need further changes?
At least Adblock Plus is no longer affected - we gave up on redirects a while ago, because of this warning. So we simply block instead.
Cc: -mpcomplete@chromium.org
This issue here is currently causing a lot of worries to users of both uBlock Origin and HTTPS Everywhere. See:

https://github.com/EFForg/https-everywhere/issues/14961

I believe this could be addressed the same way this was addressed for redirection to data: URIs:

https://codereview.chromium.org/8802017

Consider:

- Local resource = data: chrome-extension: URI
- External resource = http: https: ws: wss: etc.

Cases:

- Extension A redirect to external resource
- Extension B redirect to external resource
- Result: Conflict -- last installed extension wins

- Extension A redirect to external resource
- Extension B redirect to local resource
- Result: No conflict -- redirection to local resource wins

- Extension A redirect to local resource
- Extension B redirect to local resource
- Result: Conflict -- last installed extension wins

In short, extend the data: URI logic to chrome-extension: URIs.
I should have mentioned in my comment above: in that one instance, both "conflicting" extensions, uBlock Origin and HTTPS Everywhere, still work as intended. The issue is that the conflict warning leads users to believe the opposite and because of this they may end up thinking they need to remove one or the other, while it is unnecessary.
HTTPS Everywhere lead developer here.

Does Chromium have a plan to fix this?  This issue has been starred by 129 users, and our issue has 100 +1's: https://github.com/EFForg/https-everywhere/issues/14961

This is causing a real usability annoyance for our users.  Is there any timeline for resolving this issue?  Please let me know if you need anything from me.

It seems to me that extensions that do resource blocking or proxy social media widgets locally should get a higher priority than HTTPS Everywhere, which redirects these resources to HTTPS.  Perhaps Chromium can add a hard-coded prioritization schema, or allow extensions to specify this schema for specific resources.
Blocking: -kbsslenforcer:107
Cc: rdevlin....@chromium.org
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows
For some reason, Monorail won't let me update this bug until I remove the Blocking: kbsslenforcer:107 issue. And yet somehow that got successfully added at some point... I'll file a Monorail bug.

It links to https://github.com/kbitdk/kbsslenforcer/issues/107.
Cc: -srihariraju@chromium.org -jhurwich@chromium.org -gailh@chromium.org -jayakrishnat@chromium.org -arsids@chromium.org -vandanashah@chromium.org jawag@chromium.org bklmn@chromium.org
Labels: -OS-Linux -OS-Windows -OS-Chrome -OS-Mac
This does seem like something that would be good to prioritize.  "Extension error" (the current string we use) is very unclear, and the UI treatment we give it (showing a global error in the wrench menu) is definitely overkill.

Right now, there is a resolution process in place, which is "most-recently-installed extension wins".  This is rather opaque to the user, and may not coincide with their preferences.  If we really wanted, we could try and introduce some user-facing option for tweaking this, but I'm not sure that would be good.  I don't think that having a hard-coded priority would work well in Chromium (what would it look like?  How would it be maintained?  Who gets the top slot?).  Introducing a new bit in the API to extensions to allow them to specify "high priority" or "low priority" (or with a larger scale) may be doable, but wouldn't necessarily help with all cases (there would still be some cases that would conflict).

I wonder if instead the right approach here would be to fire the onErrorOccurred event in *all* cases that the extension's desired behavior is ignored?  It looks like we do this currently when an extension cancels a request, but not if there are competing redirects.  What if we just surfaced that error, so that the extension can make a judgment call as to whether it's a significant problem (in which case they can notify the user) or if it's perfectly fine (in which case it can be ignored)?  That seems like it would address the original concern (the extension may not be handling requests that the user thinks it is), as well as being much less alarmist than the current UI.

Any thoughts?

Also +bklmn@ for UX guidance, +karandeepb@ for webRequest, and +jawag FYI.
Regarding comment 34:  The blocking issue was added in 2014 when both the chromium project and the kbsslenforcer project were hosted on code.google.com.  It was a valid issue reference at that time.
It would be good if someone on the Chromium side took some leadership in this issue.  The immediate conflict has been mitigated by a partial reversion in uBlock origin, but this occasionally rears its head (see https://github.com/EFForg/https-everywhere/issues/14961#issuecomment-396141181).

Some way for either users, extenion developers, or Chromium itself to signal prioritization would be useful here.
NextAction: 2018-06-22
Owner: rdevlin....@chromium.org
I am rephrasing my "what if" from #35 as a concrete proposal: let's fire onErrorOccurred in these instances.  It has concrete benefits of less user noise (and hopefully confusion!), more extension insight into what's happening (and thus ability to educate the user, if it's important), and the ability to potentially delete a bit of UI code (something that always makes me happy!).

Any objections?  If not, let's make it happen!  (Setting next action for a week from today to let others chime in)
The NextAction date has arrived: 2018-06-22
Owner: karandeepb@chromium.org
Let's make it happen.

Karan, I wonder if this is something you could look into, since you've been pretty close to webRequest lately?  Hopefully the implementation should be fairly straightforward, and it's a good chance for some code cleanup. :)
I agree that the UI is pretty alarmist for no reason and not helpful to the user. I like the plan in c#38, with one small modification. Instead of firing OnErrorOccured, we should probably introduce another event OnActionIgnored, or something like that, for backwards compatibility. 

Will get to this soon-ish.

Status: Started (was: Assigned)
Summary: Handle conflicts between web request extensions gracefully. (was: adblock plus and htttps-everywhere extensions causes misbehaving extension warning)
Project Member

Comment 43 by bugdroid1@chromium.org, Jul 24

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a1a134d4548e0df6d34476d06c7c23e499f8e492

commit a1a134d4548e0df6d34476d06c7c23e499f8e492
Author: karandeepb <karandeepb@chromium.org>
Date: Tue Jul 24 20:33:28 2018

Extensions: Remove unused Warning::CreateNetworkConflictWarning.

This CL removes the unused method Warning::CreateNetworkConflictWarning. It
seems to have been introduced in r167673 without any usages.

BUG= 111700 

Change-Id: I4f209bbcabafd0f19203f970dab8341c97a256eb
Reviewed-on: https://chromium-review.googlesource.com/1148170
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577669}
[modify] https://crrev.com/a1a134d4548e0df6d34476d06c7c23e499f8e492/chrome/browser/extensions/warning_badge_service_unittest.cc
[modify] https://crrev.com/a1a134d4548e0df6d34476d06c7c23e499f8e492/extensions/browser/warning_service_unittest.cc
[modify] https://crrev.com/a1a134d4548e0df6d34476d06c7c23e499f8e492/extensions/browser/warning_set.cc
[modify] https://crrev.com/a1a134d4548e0df6d34476d06c7c23e499f8e492/extensions/browser/warning_set.h
[modify] https://crrev.com/a1a134d4548e0df6d34476d06c7c23e499f8e492/extensions/strings/extensions_strings.grd

Project Member

Comment 44 by bugdroid1@chromium.org, Jul 27

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68759d08ed2aaa7c649d79cf56759b95b654420e

commit 68759d08ed2aaa7c649d79cf56759b95b654420e
Author: karandeepb <karandeepb@chromium.org>
Date: Fri Jul 27 18:50:11 2018

Web Request: Introduce onActionIgnored event for conflicts.

This CL introduces the onActionIgnored event on the web request API which is
fired when an extension's proposed modification to a network request is ignored.
This happens in case of conflicts with other extensions. This should allow the
extensions to address conflicts as they like.

Also, we no longer notify the user in case of conflicts between extensions.

BUG= 111700 

Change-Id: I3e96740aee6b79b0823545bf17b4a50bbc8758aa
Reviewed-on: https://chromium-review.googlesource.com/1150009
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578728}
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/browser/extensions/api/web_request/web_request_api_unittest.cc
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/browser/extensions/api/web_request/web_request_apitest.cc
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/common/extensions/api/webview_tag.json
[add] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/test/data/extensions/api_test/webrequest/on_action_ignored/extension_1/background.js
[add] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/test/data/extensions/api_test/webrequest/on_action_ignored/extension_1/manifest.json
[add] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/test/data/extensions/api_test/webrequest/on_action_ignored/extension_2/background.js
[add] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/test/data/extensions/api_test/webrequest/on_action_ignored/extension_2/manifest.json
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/chrome/test/data/extensions/platform_apps/web_view/shim/main.js
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/browser/api/web_request/web_request_api.cc
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/browser/api/web_request/web_request_api.h
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/browser/api/web_request/web_request_api_helpers.cc
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/browser/api/web_request/web_request_api_helpers.h
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/browser/extension_event_histogram_value.h
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/browser/warning_set.cc
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/browser/warning_set.h
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/common/api/web_request.json
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/renderer/resources/binding.js
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/renderer/resources/guest_view/web_view/web_view_events.js
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/renderer/resources/web_request_event.js
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/renderer/web_request_hooks.cc
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/extensions/strings/extensions_strings.grd
[modify] https://crrev.com/68759d08ed2aaa7c649d79cf56759b95b654420e/tools/metrics/histograms/enums.xml

Project Member

Comment 45 by bugdroid1@chromium.org, Aug 21

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6450a953af2fcd9380c7e1d8a6a9db73aaf73f7

commit e6450a953af2fcd9380c7e1d8a6a9db73aaf73f7
Author: Karan Bhatia <karandeepb@chromium.org>
Date: Tue Aug 21 02:49:49 2018

Extensions Docserver: Bump the version.

This CL bumps the Docserver version to 3.58.0. r578728 introduced the
onActionIgnored event to the web request API. However, the documentation changes
are not yet reflected in the extension docs (due to an underlying Docserver
bug). Force a version bump for now, which should help reflect the new changes.

BUG=513780,  111700 

Change-Id: I5ef403922b4e5d0c4af0d136b9ea0b8fecf528bc
Reviewed-on: https://chromium-review.googlesource.com/1182420
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584612}
[modify] https://crrev.com/e6450a953af2fcd9380c7e1d8a6a9db73aaf73f7/chrome/common/extensions/docs/server2/app.yaml

Status: Fixed (was: Started)

Comment 47 Deleted

Sign in to add a comment