Conversation
It now allows switching btw implementations by setting a preference. livedev.multibrowser set to true enables MultiBrowserImpl.
|
Preference now added |
Remove logic for launching browser from transport. It now relies on NativeApp.openLiveBrowser
|
Removed logic for launching default browser from |
node.remove() is not supported on IE, using alternative node.parentNode.removeChild(node) in that case
|
Add fix for make it work on IE as per it was analyzed in njx/brackets-livedev2#20. |
Add integration tests for initial connection and related documents.
- Add close window based on NativeApp.closeLiveBrowser for mac - Move launch from protocol to LiveDevelopment based since already relies on NativeApp.openLiveBrowser
- move reloadCSS implementation from ExtendedRemoteFunctions to LiveDevProtocolremote with the rest of the remote commands - add method setStylesheetText to protocol to make it more representative of the implementation and also align it with CDT name - align LiveCSSDocument to the new protocol method
- nodes created with new stylesheet text are now removed when the stylesheet is removed - make updates on import-ed CSS work in Firefox
It also implements getStylesheetText on remote protocol and fixes respond (there was no previous usage of it).
test for pushing in-memory changes
Conflicts: src/LiveDevelopment/main.js
1 participant
This is an alternative approach to #3 for including livedev2 in Brackets core as an experimental implementation as it was discussed in njx/brackets-livedev2#24.
LiveDevelopmentuntouched -> dependent extensions do not have to be modifiedlivedev2implementation under/LiveDevelopment/MultiBrowserImplfolder which is probably not the more fancy way (under a second level) but allows integration be less intrusive.livedev2/LiveDevelopment.jsout toLiveDevelopmentroot folder and renamed it toLiveDevMultiBrowser.jslivedev2/main.jsmain.jsto allow switching implementations:@busykai, please review it. Thanks!