Community
Participate
Working Groups
URIs like http://localhost:8080/git/commit/84cfd3a21658fee0fdb0df523e24153c334f2944/file/E/bundles/org.eclipse.orion.client.git?parts=body return the content of Git commits. I wanted to open the Orion editor to show the commit content, the link was http://localhost:8080/coding.html#http://localhost:8080/git/commit/84cfd3a21658fee0fdb0df523e24153c334f2944/file/E/bundles/org.eclipse.orion.client.git?parts=body I noticed that the editor displayed the response from http://localhost:8080/git/commit/84cfd3a21658fee0fdb0df523e24153c334f2944/file/E/bundles/org.eclipse.orion.client.git instead of http://localhost:8080/git/commit/84cfd3a21658fee0fdb0df523e24153c334f2944/file/E/bundles/org.eclipse.orion.client.git?parts=body. So it seems like the parameters of the resource URI are chopped off. Could you please fix it?
In coding.html we use the hash to store the URL of the resource being edited, and also to provide "line" and "char" parameters in a query-style format, Eg. coding.html#/path/to/file.txt?line=25&char=6 This is ambiguous when the resource URL includes "?&". For example we can't distinguish between > coding.html#file.txt?parts=body and > coding.html#file.txt?line=25 This is a design issue that we need to solve.
To stop blocking Szymon, I've made coding.html more conservative when it parses the hash. It now only assumes that "char" and "line" are parameters for the editor, and leaves stuff like ?parts=body alone. I opened Bug 340458 for discussion of our hash-usage approach.
