my bad, turned out it's related to spiffyui, here's a small project to
demonstrate the bug: https://github.com/mbsimonovic/spiffyui-hash-bug. So
just excluding spiffiui.min.js fixes the bug. I'm gonna write to the
spiffyui developers...
ms
On Thursday, May 16, 2013 1:09:41 PM UTC+2, Thomas Broyer wrote:
>
>
>
> On Thursday, May 16, 2013 1:02:19 PM UTC+2, milan wrote:
>>
>> found the reason, the nocache.js script tag was before the history iframe.
>>
>
> This is really strange!
> …as the iframe is only used by IE6/7, and you were reporting issues in
> Firefox, Chrome and Safari.
>
>
>>
>> regards,
>> Milan
>>
>> On Wednesday, May 15, 2013 11:33:44 AM UTC+2, milan wrote:
>>>
>>>
>>> I'm getting some weird behavior with Activities&Places (GWT 2.4.0 and
>>> 2.5.1), in FF 20/21/Chrome/Safari 6, both prod and dev mode.
>>>
>>> Here's an example:
>>>
>>> with @Prefix("!contact") these two urls work just fine ('contact' place,
>>> token first empty then 'department'):
>>>
>>> http://127.0.0.1:8888/?gwt.codesvr=127.0.0.1:9997#!contact:
>>>
>>> http://127.0.0.1:8888/?gwt.codesvr=127.0.0.1:9997#!contact:department
>>>
>>>
>>> but when I try to open:
>>>
>>>
>>> http://127.0.0.1:8888/?gwt.codesvr=127.0.0.1:9997#!contact:department/1
>>>
>>>
>>> the url gets rewritten to:
>>>
>>> http://127.0.0.1:8888/!contact:department/1
>>>
>>>
>>> and the app goes to the default place (historyToken is empty) and
>>> there's a 404 because !contact doesn't exist. Debugging this I get to
>>> c.g.g.user.client.impl.HistoryImpl.java#133 newItem() that is called
>>> with an empty historyToken so this happens before any tokenizers get
>>> called. The same happens when token contains period/dot (.) or question
>>> mark. Anyone seen this before?
>>>
>>> It's been known this can happen because of 3xx
>>> redirects<http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx>,
>>>
>>> but this is not the case here (then all fragments would be dropped). To be
>>> sure this is not the case, I tried this with a redirect: a simple filter to
>>> remove "index.html" so that
>>> 127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997#!downloads: gets
>>> redirected to 127.0.0.1:8888/?gwt.codesvr=127.0.0.1:9997#!downloads: and
>>> it works correctly. Inspecting HTTP requests under the hood also doesn't
>>> show any 3xx responses when hash gets dropped.
>>>
>>> Could this be a bug?
>>>
>>> regards,
>>> Milan
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
