Bug #808
closedImages don't get loaded properly anymore
0%
Description
Hi,
I just upgraded from a 3.1.8 version to a current git snapshot and images aren't loaded properly anymore. The images on the first page the applications shows work properly, but if I change (with the menu) to an other page, I see my browser doing requests to a url that's a combination of the location of application and real url. Which also has as nice side effect that for all images a new application is started.
Kurt
Updated by Wim Dumon over 13 years ago
Hello Kurt,
We've been making some changes that may impact this.
Does this happen with all browsers?
Do you use the brand new baseUrl feature?
Can you give examples of the url that you expect and those that are requested?
Thank you,
Wim.
Updated by Kurt Roeckx over 13 years ago
Wim Dumon wrote:
Hello Kurt,
We've been making some changes that may impact this.
Does this happen with all browsers?
It affects at least firefox 4.0 and chrome 11.
Looking at the page with lynx I can't reproduce the broken behavior.
Do you use the brand new baseUrl feature?
No, don't know about it yet.
Can you give examples of the url that you expect and those that are requested?
If the app is "/app.wt", and the image is "/pics/1.jpg", the request goes to "/app.wt/pics/1.jpg"
Kurt
Updated by Kurt Roeckx over 13 years ago
Kurt Roeckx wrote:
Wim Dumon wrote:
> Does this happen with all browsers?It affects at least firefox 4.0 and chrome 11.
Looking at the page with lynx I can't reproduce the broken behavior.
That should be "I can reproduce". Looking at the html the broken urls are in it.
Updated by Koen Deforche over 13 years ago
- Assignee set to Koen Deforche
Hey Kurt,
Is the image src an absolute URL ("/pics/1.jpg") or a relative URL ("pics/1.jpg") ?
The new HTML5 API has as consequence that you now also with JavaScript enabled, in a modern browser, you need to either use absolute loations for resources (like images) or you need to set the (kind of new) baseURL property to point to the absolute URL which is used to resolve relative paths. This isn't actually a breaking change since in sessions without JavaScript this behavior already existed.
The baseURL property should be configured in your wt_config.xml, to something like "http://localhost:9090/dir/" if your application is deployed at the path "/dir/app.wt" or "/dir/".
Regards,
koen
Updated by Kurt Roeckx over 13 years ago
Koen Deforche wrote:
Hey Kurt,
Is the image src an absolute URL ("/pics/1.jpg") or a relative URL ("pics/1.jpg") ?
It seems I give "pics/1.jpg" to the WImage, while I was expecting that I give a "/pics/1.jpg" to it.
The new HTML5 API has as consequence that you now also with JavaScript enabled, in a modern browser, you need to either use absolute loations for resources (like images) or you need to set the (kind of new) baseURL property to point to the absolute URL which is used to resolve relative paths. This isn't actually a breaking change since in sessions without JavaScript this behavior already existed.
You're of course right that with the HTML5 API the url of the page is changed, so that it shouldn't actually find it. But I think there are some other things broken in that case since it works for the first page I go to, which should also already have the path set.
The baseURL property should be configured in your wt_config.xml, to something like "http://localhost:9090/dir/" if your application is deployed at the path "/dir/app.wt" or "/dir/".
I can certainly try making it an absolute path or setting the baseURL.
Kurt
Updated by Koen Deforche over 13 years ago
- Status changed from New to Resolved
Hey,
There were still issues with relative URL resolution. This has been fixed in git head.
Regards,
koen
Updated by Koen Deforche over 13 years ago
- Status changed from Resolved to Closed