Initial work on upgrading OpenWPM to Firefox ESR 60 #221
Conversation
motin
force-pushed
the
fx60-esr-init
branch
3 times, most recently
from
8ca5f73 to
133135f
Compare
|
(Note that travis is not be able to install the proper selenium package due to SeleniumHQ/selenium#6470 - thus all travis tests fail until the upstream issue is fixed or a workaround is implemented) |
motin
force-pushed
the
fx60-esr-init
branch
3 times, most recently
from
3e79ad0 to
aaff4ed
Compare
|
This is ready to merge into the develop branch. |
motin
force-pushed
the
fx60-esr-init
branch
2 times, most recently
from
6561d52 to
bbcd0d8
Compare
(at the time of the merge of openwpm/OpenWPM#221)
(at the time of the merge of openwpm/OpenWPM#221)
Fix Dockerfile-dev build, by ADDing requirements-dev.txt to /opt/Open…
| "content.js" | ||
| ], | ||
| "run_at": "document_start", | ||
| "all_frames": true |
There was a problem hiding this comment.
We should also add "match_about_blank": true, (see: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_scripts). Note that about:blank iframes can execute JS as they are same-origin to the embedding frame (https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Inherited_origins).
|
|
||
| // Wait for window.instrumentObject to be set by | ||
| // the injected page script before continuing | ||
| const instrumentObjectAvailable = new Promise(function(resolve) { |
There was a problem hiding this comment.
I know we discussed this briefly on our call, but I don't remember the conclusion. Can you reiterate why we experience a delay, i.e. why injecting at document_start isn't sufficient? This will cause us to miss JS calls that happen very early during a page visit.
There was a problem hiding this comment.
Currently, there is no way for webextensions to inject page scripts before any ordinary web content is loaded, so there is always a race condition between the ordinary web content and the injected page script, hence this wait for the instrumentation to be available before attempting to use it. Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1378459
There was a problem hiding this comment.
Ah, if I'm understanding Bug 1378459 correctly, the issue is related to extension startup and thus will be present on the first page load only right? I suspect we can have the browser manager process block on a signal from the extension before submitting the first top-level request. I'll file a new bug for this.
…nsion boilerplate and usage of socket.io instead of legacy sdk socket + port.emit
…ent and vice versa
…saging in lieu of raw network sockets and file system access. Http and cookie instrumentation currently only holds placeholders for updated instrumentation, but javascript instrumentation works. Aggregators are yet to be reinstated.
… page script before continuing
…an be installed to the profile
…t it in the readme
…r is not available
|
Rebased and ready for merge. Also including the latest commits to master, so that the develop branch is up to date. |
Work in progress, not ready for merge yet. Created for discussion and ongoing review purposes.
Relates to #148
@englehardt In order to make this a collaborative effort, please create a
firefox-upgradeordevelopbranch in the OpenWPM repo for this PR to target, so that the master branch can still be used for bugfixes to the stable version while we get the major version upgrade in order.(Note: this PR includes the commits from #219 as well. It is advised to first review and merge that PR, whereafter this PR will be rebased on the current master branch, making it easier to review)
EDIT: #219 has been merged and this PR has been rebased.