Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 359718

Summary:	All local URLs need to be relative
Product:	[ECD] Orion	Reporter:	Simon Kaegi <simon_kaegi>
Component:	Client	Assignee:	Simon Kaegi <simon_kaegi>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	libingw, mamacdon, susan
Version:	0.2
Target Milestone:	0.3 RC2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Simon Kaegi

2011-10-03 11:24:27 EDT

For local URLs we're using thing like '/images/folder.png' in our css files and our script references in our HTML files are also using '/requirejs/require.js'. We need to stop doing this as it prevents us and others from moving the code around and in particular of the web server root.

All local URLs should NOT start with '/' and instead should use relative syntax. e.g. '../images/folder.png'

Comment 1 Szymon Brandys

2011-10-05 07:53:11 EDT

it should be rather ../../orion/images/folder.png

Comment 2 libing wang

2011-10-05 09:46:37 EDT

(In reply to comment #1)
> it should be rather ../../orion/images/folder.png
I am curious here.
Noticed that Simon refactored them , like , e.g.
require.toUrl("images/file.gif")
Should we just assume that .toUrl knows how to convert it ?

Comment 3 Simon Kaegi

2011-10-05 11:44:28 EDT

To be honest I'd prefer it if there were NO image URLs in our JavaScript files. Instead it would be better to use a class and a css file that knows about the image. We need to keep things like "style" and "icons" out of our JavaScript and instead reference by class and do the styling in CSS -- just common sense.

Comment 4 Susan McCourt

2011-10-05 12:07:26 EDT

(In reply to comment #3)
> To be honest I'd prefer it if there were NO image URLs in our JavaScript files.

We are working toward this in bug 349237.

Comment 5 Malgorzata Janczarska

2011-10-06 08:48:03 EDT

I've corrected fileClientPlugin.html. It used window.location.origin to make the path relative, but window.location.origin exists only on Chrome. fileClientPlugin.html coulnd't install on FF and IE. I've changed it to smart use of window.location.host.

Comment 6 Simon Kaegi

2011-10-06 10:20:24 EDT

Good catch. Thanks Gosia.

Comment 7 Simon Kaegi

2011-10-06 10:25:23 EDT

I've added a protocol check to the logic to make sure we don't try to make http and https resources relative

Comment 8 Simon Kaegi

2011-10-07 16:31:49 EDT

We're generally in good shape here on the client now. I'll leave this open and do more checks for RC2.

Comment 9 Mark Macdonald

2011-10-12 15:42:57 EDT

When running the server with a different context path (/cc), the git-clone page doesn't work. It tries to call /gitapi/ URLs rather than /cc/gitapi/.

Also, I noticed that GitRemoteHandlerV1 and GitCommitHandlerV1 are doing path math to get a task URL:

> private URI createTaskLocation(URI baseLocation, String taskId) throws URISyntaxException {
>     return new URI(baseLocation.getScheme(), baseLocation.getAuthority(), "/task/id/" + taskId, null, null); //$NON-NLS-1$
> }

That looks like it will fail too.

Comment 10 Simon Kaegi

2011-10-19 12:30:01 EDT

Marking fixed retroactively based on what we've done for 0.3.

We still have work here for our Git Client and Server but I'll open a different bug for 0.4 to track that work.