1026674 - Project editor: Enable pairing between filesystem and page

Status: RESOLVED INVALID

(DevTools Graveyard :: WebIDE, defect, P3)

Description

[Brian Grinstead [:bgrins]]

We removed Pairs when landing the original project editor (https://bugzilla.mozilla.org/show_bug.cgi?id=987089#c32).  This is the concept of live updating a resource on the page as the resource on disk changes, similar to how the style editor works.

This is a neat feature and the app manager is an 'easy' target for this kind of behavior, since there is a 1:1 mapping from the resource on disk with the one being loaded on the page.

It isn't exactly the same thing, but it could expand into the concept of Resource Maps (https://github.com/mozilla/devtools-reqs/blob/master/resource-maps/index.md), which has to do with going from devtools back to the file system.

Comment 1

[Brian Grinstead [:bgrins]]

We also need to share Fronts with the style editor so there isn't an error when having both the project editor and the toolbox opened on the same target.  There is an example of doing this in getDeviceFront here: http://dxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/device.js#227.

Comment 2

[Paul Rouget [:paul]]

I don't think this should block enabling the new appmgr.

So when we're connected to the device, a projecteditor panel would behave like the StyleEditor? And this will only work with CSS.

How do we make sure this is not confusing for the user?

Comment 3

[Paul Rouget [:paul]]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #2)
> How do we make sure this is not confusing for the user?

I mean, writing CSS code would auto-updated the app, but not HTML and JS.

Comment 4

[Brian Grinstead [:bgrins]]

Attachment: project-pairing-WIP.patch

Just a WIP patch for this pairing - there are probably some UX things we would need to deal with as mentioned in Comment 2 and 3

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #3)
> (In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from
> comment #2)
> > How do we make sure this is not confusing for the user?
> 
> I mean, writing CSS code would auto-updated the app, but not HTML and JS.

I have the following modest proposal for the time being:

* css editing is 'live' from projecteditor while debugging
* we consider disabling the style editor from the toolbox to reduce confusion over the preferred way to edit css. Currently we have two ways that can easily get out of sync with each other.
* we consider reloading the app *on save* as an option to emulate liveReload on file change.

Where this gets us is:

* if you're not debugging, the app is reloaded to see changes on Ctrl+R or optionally on save
* if you're debugging, css is updated live but js/html are update when the app is reloaded by ctrl+r or on save

I think the additional thing we would need to make this work is the ability to preserve unsaved css changes over reloads or alternatively auto-save unchanged css files on reload.

Comment 6

[Brian Grinstead [:bgrins]]

I'd be fine with just copying over style changes on editor save (instead of any keypress) if that simplifies things.  It would at least fit the liveReload mindset that people may be used to.  If this were the case, we could still allow Style Editor to be opened when debugging (and maybe even allow it to already know the paths for its files so pressing ctrl+s in the style editor wouldn't need to open a prompt).

I like the idea of also being able to detect file changes from external editors and use the same (or similar) behavior that we do when the change happens from within Project Editor.

I think any of this pairing activity should be optional, but it could be a nice way to start integrating with external editors.  I'm not sure if the optional part is best enabled by starting a debugging session or through some other option in the UI, but while debugging seems like a reasonable default.

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Filter on TEAPOT-SPLINES.

Seems like we have good ideas here that we should revisit if we invest in synced resources.

Comment 8

[Sebastian Zartner [:sebo]]

(In reply to Brian Grinstead [:bgrins] from comment #6)
> I think any of this pairing activity should be optional, but it could be a
> nice way to start integrating with external editors.  I'm not sure if the
> optional part is best enabled by starting a debugging session or through
> some other option in the UI, but while debugging seems like a reasonable
> default.

FWIW, this is an often requested feature for Firebug. Regarding opening files in external editors, I've created bug 1270733.
The integration between external editors and the DevTools should be as seamless as possible.

Sebastian

Comment 9

[Patrick Brosset <:pbro>]

Projecteditor was removed from the tree in bug 1361311.