We should think more carefully how we use the various kinds of browser local storage, especially with regard to moving content between different origins. Once we've edited an origin we don't own we find our work held captive by the origin domain even though that domain, has offered cross-origin resources sharing (CORS).
Our current practice is to store edits that can't otherwise be saved as local copies of server pages. We indicate this condition with a yellow border and use the site psudo-domain "local" in the location bar. Our drag-and-drop sharing mechanisms break down in this case. The one supported way to save our work is with the Submit Changes mechanism of the Ruby/Sinatra implementation. This creates a numbered subdomain on the un-owned server to hold our work.
A better approach would be to drag the page to a tab operating from an origin that we do own and eventually fork the content from our browser to that site. This client to server forking does work in some situations. The server can accept a complete page from the server and store it as its own. This is a variation of the 'fork' action.
Unfortunately the CORS properties of server pages are not inherited by content stored by those pages in browser local storage, as we use that storage now.
With this issue I am asking that we explore alternative forms of local storage that might have the CORS properties we currently enjoy from server pages. Or, possibly, suggest that the loss of CORS properties is a browser bug that should be fixed in all modern browsers.
Our most likely recourse is to handle the 'local' psuedo-site differently, possibly with a complete rethinking of the client-side server-facing interface now captured in lib/pageHandler.
We should think more carefully how we use the various kinds of browser local storage, especially with regard to moving content between different origins. Once we've edited an origin we don't own we find our work held captive by the origin domain even though that domain, has offered cross-origin resources sharing (CORS).
Our current practice is to store edits that can't otherwise be saved as local copies of server pages. We indicate this condition with a yellow border and use the site psudo-domain "local" in the location bar. Our drag-and-drop sharing mechanisms break down in this case. The one supported way to save our work is with the Submit Changes mechanism of the Ruby/Sinatra implementation. This creates a numbered subdomain on the un-owned server to hold our work.
A better approach would be to drag the page to a tab operating from an origin that we do own and eventually fork the content from our browser to that site. This client to server forking does work in some situations. The server can accept a complete page from the server and store it as its own. This is a variation of the 'fork' action.
Unfortunately the CORS properties of server pages are not inherited by content stored by those pages in browser local storage, as we use that storage now.
With this issue I am asking that we explore alternative forms of local storage that might have the CORS properties we currently enjoy from server pages. Or, possibly, suggest that the loss of CORS properties is a browser bug that should be fixed in all modern browsers.
Our most likely recourse is to handle the 'local' psuedo-site differently, possibly with a complete rethinking of the client-side server-facing interface now captured in lib/pageHandler.
See related issues #420 #412 #352 #342