Skip to content
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

Backend pieces of auto-update enable/disable #548

Merged
merged 1 commit into from
Apr 12, 2016

Conversation

humphd
Copy link

@humphd humphd commented Apr 7, 2016

This updates Brackets for the API changes necessary for https://github.com/mozilla/thimble.mozilla.org/issues/1417.

There are 2 types of "reloads" that we do. The first is a full reload for cases where the DOM needs to be altered in a way that can't be done easily, which is like refreshing the browser tab. The second is a dynamic injection of content that doesn't warrant a full reload. For example, updating the text in a paragraph tag.

This patch makes it possible to stop the first kind of reload, which is what I think we want. If we decide that we also want to stop the second type, it's going to be hacky. I would need to inspect messages going over the LiveDev transport, and look for things like "_LD.applyDOMEdits([{"type":"textReplace"... deep inside the string of a Runtime.evaluate message. I could do this, but if I don't have to, I'd rather not.

cc @flukeout
r? @gideonthomas

@humphd
Copy link
Author

humphd commented Apr 7, 2016

It looks like if I want to do 2), I could also try to prevent it at the source, which is https://github.com/mozilla/brackets/blob/master/src/LiveDevelopment/MultiBrowserImpl/documents/LiveHTMLDocument.js#L212-L229, specifically line 221. I'd just need to wrap this in a guard that can be enabled/disabled via the Bramble client.

@humphd
Copy link
Author

humphd commented Apr 8, 2016

One thing to consider here: our highlighting code depends on the DOM being a) up-to-date such that b) DOM nodes referenced in the editor actually exist in the preview. If the editor and preview are allowed to drift out of sync dramatically, the highlighting code is going to get more and more unusable, as new additions to the editor cease to appear in the preview.

@gideonthomas gideonthomas self-assigned this Apr 8, 2016
@gideonthomas
Copy link

I don't think we should support the second case. From what I understand, the issue was that it was annoying that the preview was flickering because of a full refresh (the first case). So allowing a toggle on that should be fine. Toggling live dev based on LiveDocuments might be overkill. I think we we make it clear in the UI that should be fine.

As for the highlighting code, we can force a reload (which should sync DOM elements) when it is toggled, can't we?

@gideonthomas
Copy link

The patch itself lgtm! r+

@flukeout
Copy link

Okay, I'm going to start work on a companion PR in Thimble to match this effort. Will holler if I run into problems.

@humphd
Copy link
Author

humphd commented Apr 12, 2016

@flukeout I'm going to land this. If we decide to change the disabled state to also block dynamic injection, we can do it in a new patch. I think that @gideonthomas is right, we probably don't want it.

@humphd humphd merged commit b5e1df4 into mozilla:master Apr 12, 2016
@flukeout
Copy link

@humphd okay perfect, PR incoming for the toggle later today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants