New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
avoid sync messages on document load #2259
Conversation
old: strings sent via e10s message manager are duplicated and the sandbox holds onto them as source code, this causes unnecessary memory overhead. new: load scripts from file:// URIs and use lazy getters for scriptSource
The warning: Services.ppmm (Services.mm, Services.cpmm) Not compatible for Firefox 38.0.5- |
What's the overall approach here? Effectively the whole config of all scripts and their include/exclude data is stored in every child all the time? And the fileXhr trick means that we don't have to duplicate the script itself? |
ok, will fix that
Is there some auto-formatter I could apply? That's more a job for a machine than a human.
Once you looked at the other two you only need to review f21e40a
Yes. In each child process, not in each frame. Additionally, the old code used the sync messages to check for script refreshes, this now piggybacks on http observers which carry similar information to the sync messages anyway. We can extract all the necessary information from requests with |
The warning: initialProcessData Not compatible for Firefox 42- (maybe 41- , https://bugzilla.mozilla.org/show_bug.cgi?id=1162838 , but: 41.0b6 - in this version does not work). |
this.localized = aScript.localized; | ||
this.matches = aScript.matches.map(function(m) { return m.pattern; }); | ||
this.userMatches = aScript.matches.map(function(m) { return m.pattern; }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it should be: matches => userMatches
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, thanks
@janekptacijarabaci thanks for testing, I think those issues should be fixed now. |
You're welcome. However, I see another problem... After editing the script in Scratchpad (e.g.) and saving - properties of the object (GM_info) is not valid (is not changed): |
@janekptacijarabaci when I save + refresh the page demo: https://i.pantsu.cat/lemhtw.webm It's pretty much the same old logic, just that it infers a page load from a HTTP observer instead of relying on sync messages from the frame script: https://github.com/the8472/greasemonkey/blob/f21e40a74147e409231e39b08f9387e55cc0cb07/modules/refererSetter.js#L33-L53 |
I'm sorry, but I do not work for me. Steps to reproduce:
I don't have time to find the bug now... |
when = "any": this value does not exist...Fix this bug (for example): From: GM_util.getService()
.scriptRefresh("any", channel.URI.spec, windowId, browser); To: GM_util.getService()
.scriptRefresh("document-start", channel.URI.spec, windowId, browser);
GM_util.getService()
.scriptRefresh("document-end", channel.URI.spec, windowId, browser); ...or: From: .scriptRefresh("any", channel.URI.spec, windowId, browser); To: .scriptRefresh(channel.URI.spec, windowId, browser); From: service.prototype.scriptRefresh = function(when, url, windowId, browser) { To: service.prototype.scriptRefresh = function(url, windowId, browser) { From: this.config.updateModifiedScripts(when, url, windowId, browser); To: this.config.updateModifiedScripts("document-start", url, windowId, browser);
this.config.updateModifiedScripts("document-end", url, windowId, browser); |
- beam down IPCScripts in advance from parent when a script changes - do script filtering/url matching in content process - piggyback script change detection on http observers instead by checking document/sub-document loads
4f0dd3f
to
70fab3e
Compare
ok, incorporated your changes and rebased on master |
I've started merging this down. It's a huge change, I want to give it some time to bake before I commit it to master. |
@arantius: @the8472, @arantius: |
Point one: no, intentional, merge conflict with c274845 . Point two: good catch! |
See #2289 -- doesn't work with e10s off. Looking into why now. |
Also not working in FF 44 with e10s off, so e10s off appears to be the real issue. |
Odd, I did test with e10s off, maybe I skipped that during the recent rebase. Anyway, how do you want fixes? New commits on this PR? Rebase? Or against your own branch? |
Gimme 5, I might be near a "fix". Something at appears to work better, assuming I understand the operating model. |
Hum, was that some merge conflict? The broadcast shouldn't have been in an |
Indeed, must have been my fault somehow. Whoops, there it is. |
What about the script refresh part? |
I didn't know it existed because it was in a file called |
The reminder (a typo): |
The suggestion: |
Merged this into master. |
This removes the sync
greasemonkey:scripts-for-url
message from the framescript.builds on work from PR #2243 and #2255