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

Issue 725917 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

No content (status 204) frame access issues in chrome javascript api

Reported by drol...@yahoo.com, May 24 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce the problem:
1. Navigate browser to a page containing a frame with src url for a resource returning http status 204 (no content). In my tests, using "https://cm.g.doubleclick.net/push?client=ca-pub-7439281311086140&aid=24216668,37567192,42291895,88631162,171398489"
2. The frame is created in the page with a document location of "about:blank". The contentDocument of the frame is just a simple skeleton with <html><head><body> and no content. Javascript can add content to the frame.

What is the expected behavior?
1. A call to chrome.webNavigation.getAllFrames returns all frames, including this no content frame
2. A call to chrome.tabs.executeScript targeting this frame works without error

What went wrong?
1. The call to getAllFrames does not include this no content frame in results
2. A call to executeScript targeting this frame generates a runtime.lastError object with message "The frame was removed". However, the script IS executed and the frame is not removed.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 58.0.3029.110  Channel: stable
OS Version: Ubuntu 16.04
Flash Version:
 

Comment 1 by drol...@yahoo.com, May 24 2017

The only event that seems to fire for the no content frame is webNavigation.onBeforeNavigate. The events onCommitted, onDOMContentLoaded, and onCompleted never fire. Using the manifest to inject scripts doesn't work because the no content frame is ignored even for <all_urls> and matchAboutBlank = true. For an extension that wants to execute something in all frames, but can wait until later in the load process (for better user experience), this is a difficult situation. 
Labels: Needs-Triage-M58

Comment 3 by jochen@chromium.org, May 25 2017

Components: -Blink>JavaScript Platform>Extensions>API
Labels: -OS-Linux OS-All
Owner: nasko@chromium.org
Status: Assigned (was: Unconfirmed)
Labels: TE-NeedsTriageHelp
The issue seems to be out of TE-scope. Hence, adding label TE-NeedsTriageHelp for further investigation.

Thanks...!!

Comment 5 by drol...@yahoo.com, Aug 10 2017

Bumping in case this has fallen through cracks ...

Comment 6 by nasko@chromium.org, Aug 18 2017

Thanks for the bump, it indeed had fallen through. I've managed to repro locally and will investigate, however I will be out of office for a next week, so it won't be immediately.

Comment 7 by nasko@chromium.org, Aug 18 2017

Cc: clamy@chromium.org rdevlin....@chromium.org
It looks like with PlzNavigate, we treat 204/205 as an actual error, which means we don't send anything to the renderer process (https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_request.cc?rcl=4d7a9ea81684ff23d235642fa97f5bbd110911f5&l=642). Inside the webNavigation API implementation, we don't track frames that haven't committed and because of the ERR_ABORTED treatment, the frame is not added to the tracking list, which in turn means we don't add it to the output of getAllFrames. 

Without PlzNavigate, we don't go through the same path as above, however we still get a DidFinishNavigation which has NavigationHandle with HasCommitted and IsErrorPage both set to false, which causes the same skip of adding to the state tracking list.

Adding rdevlin.cronin@ to look at tabs.executeScript, as it doesn't use the same underlying state tracking, so not sure why that one gives us an error.
Cc: nasko@chromium.org
Owner: ----
Status: Available (was: Assigned)

Sign in to add a comment