Navigating to URL containing query string in headless mode in a docker image results in NotifyBeforeURLRequest being empty and "start is not defined" error
Reported by
brandon....@gmail.com,
Feb 15 2018
|
|||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36
Steps to reproduce the problem:
1. Run Jenkinsfile containing step described in attached JenkinsFile file (note that code therein is just a snippet, to reproduce, plop in a standard jenkinsfile operating on Ubuntu 14.04.3 LTS)
What is the expected behavior?
Call to
/usr/bin/google-chrome \
--headless \
--remote-debugging-port=9222 \
--allow-file-access \
--disable-web-security \
--user-data-dir=${HOME} \
--enable-logging \
--v=1 \
${env.BUILD_URL}?foo=bar &
should load the website at BUILD_URL with the query string supplied.
What went wrong?
If NO query string is supplied, the URL loads fine (see full description of diagnosis at https://groups.google.com/a/chromium.org/forum/#!topic/headless-dev/bjpE-QXF4Yo). If a query string is supplied, the initial NotifyBeforeURLRequest is at an empty file:/// (again see logs at the groups forum). If the query string is not supplied, this initial NotifyBeforeURLRequest points to the actual page. As a result of attempting to open file:/// the browser correctly fails out with errors of the following sort:
[0215/145852.132684:INFO:CONSOLE(1)] "Uncaught ReferenceError: start is not defined", source: file:/// (1)
[0215/145852.132825:INFO:CONSOLE(2)] "Uncaught ReferenceError: addRow is not defined", source: file:/// (2)
(though incorrectly obviously attempts to load an empty url even though I didn't request it).
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 64.0.3282.167-1 Channel: n/a
OS Version: Ubuntu 14.04.3
Flash Version: N/A
Attempts to diagnose the issue include:
* quoting (single and double) the url - makes no difference
* running on a linux machine outside of a docker context - runs as expected
* attempting to load some other page than BUILD_URL, i.e. www.google.com - This fails in the same fashion
* navigating without query string - loads URL correctly (though the query string is paramount to the point of this particular jenkins step)
,
Feb 15 2018
Should be noted that the only thing off of a base image of Ubuntu installed on the machine is Node6
,
Feb 16 2018
Aha, seem to have found an element of the issue. If I supply the protocol, (i.e. I say file:///<CWD>/bin/...index.html?foo=bar as opposed to just /bin/...index.html?foo=bar) the it seems to get further. I'm not seeing the logs I'm expecting from the page actually running, but it's also not throwing up the same error message. Perhaps Chrome is trying to guess the protocol and is not able to and just throws it's hands up and doesn't do anything in that case?
,
Feb 16 2018
ccing skyostil@ from the forum link https://groups.google.com/a/chromium.org/forum/#!topic/headless-dev/bjpE-QXF4Yo as per comment #0 and adding label TE-NeedsTriageHelp for further investigation and requesting skyostil@ for help in triaging the issue further. Thanks...!!
,
Feb 19 2018
In general you should always pass fully qualified URLs to Chrome. If you do that, is there some other error you're hitting here?
,
Feb 20 2018
No, adding a fully qualified URL does solve the problem (and I've since worked around all other issues I had related to it). It's just odd that Chrome guesses the correct intended action when not given a query string but seems to error out when given one. However, now that I have the answer (and will shortly update the group post for anyone else hitting it) I can see either prioritizing the issue very low or closing out the bug as WF.
,
Feb 20 2018
As an additional note, Chrome will interestingly find the correctly pathed file when NOT given the file protocol (and I assume it guesses that I wanted the file protocol). However, if given the file protocol the same path will fail (because it is not a direct full path). In other words whereas I could get the file to load with ${env.BUILD_URL} with no protocol (BUILD_URL returns essentially the bin folder path created by a jenkins gulp), I need to supply file:///$WORKSPACE/$env.BUILD_URL if using the protocol handler. An odd callout and I'm honestly not sure how Chrome is figuring out where the index file is given that I'm not hosting a server that would tell it where the relative path should be appended to.
|
|||
►
Sign in to add a comment |
|||
Comment 1 by manoranj...@chromium.org
, Feb 15 2018