possible bug: hash fragment gets dropped when some special characters are present (period, slash...)

66 views
Skip to first unread message

milan....@gmail.com

unread,
May 16, 2013, 12:16:46 PM5/16/13
to spif...@googlegroups.com
Hey guys,

could you please have a look why spiffyui.min.js gets the hash fragment dropped: https://github.com/mbsimonovic/spiffyui-hash-bug 

GWT 2.4.0 and 2.5.1, in FF 20/21/Chrome/Safari 6, both prod and dev mode. 

In the provided example, 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: 

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 toc.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.

regards,
Milan

Zack Grossbart

unread,
May 16, 2013, 12:28:20 PM5/16/13
to spif...@googlegroups.com
Hello Milan,

I'm not sure I follow you. We are doing some rewriting and handling of the
hashes on the history. I don't think we do anything special with slashes in
the hash. Do you have a sample project for this?

Why are you trying to use hash-bang instead of hash? If you want to do
hash-bang history handling you'll need to implement some server-side code as
well.

You might be interested in this article as well:


http://coding.smashingmagazine.com/2011/09/27/searchable-dynamic-content-wit
h-ajax-crawling/

Cheers,
Zack
--
You received this message because you are subscribed to the Google Groups
"Spiffy UI" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to spiffy-ui+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Milan Simonovic

unread,
May 16, 2013, 12:34:02 PM5/16/13
to spif...@googlegroups.com
Hi Zack,

this is the sample project for you to reproduce the behavior: https://github.com/mbsimonovic/spiffyui-hash-bug
go into the webapp folder and run mvn gwt:run.

ms

You received this message because you are subscribed to a topic in the Google Groups "Spiffy UI" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spiffy-ui/mVtaWOkdkd8/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to spiffy-ui+...@googlegroups.com.

Zack Grossbart

unread,
May 16, 2013, 2:00:51 PM5/16/13
to spif...@googlegroups.com
Hi Milan,

I downloaded the project and I see the issue, but I'm not sure what's going
on. The browser history support in Spiffy UI depends on a framework called
history.js. That framework does use fragments in some cases to control
history and it may be getting confused with slashes and question marks.

The URL specification is a little unclear here, but some Googling around
gave me the quick answer that you should probably encode all special
characters, like slash and question mark, that you want to use in the URL
fragment.

You're email inspired me to upgrade Spiffy UI to the last version of
history.js so you might want to try the latest snapshot of Spiffy UI, but my
guess is it won't change this behavior. This sounds like it comes down to a
case of don't do that. I would encode any special characters you want to
use in the hash fragment.

Thanks,

milan....@gmail.com

unread,
May 16, 2013, 2:32:06 PM5/16/13
to spif...@googlegroups.com, za...@grossbart.com
Zack thanks for checking. My first thought was that it was an encoding problem but it's not, just try escaping dot or slash and you'll still see the problem (encoding . with %2E):

http://127.0.0.1:8888/?gwt.codesvr=127.0.0.1:9997#!contact:department%2E1 

The other thing is, according to the URI RFC 3986, these characters do not have to be encoded:
"Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde."

So from my point of view this is a bug. 

regards,
Milan

Zack Grossbart

unread,
May 16, 2013, 2:44:45 PM5/16/13
to spif...@googlegroups.com
Hi Milan,

I can see that. Please feel free to enter it. However, with a simple work around of not using those characters it's probably not going to get fixed too soon.

There is an option to disable Spiffy UI history integration. Just add a little JavaScript to the top of your page and put this:

spiffyui.History.enabled = false;

That will turn off the history support and probably work around this issue.

Thanks,
Zack

milan....@gmail.com

unread,
May 16, 2013, 2:58:08 PM5/16/13
to spif...@googlegroups.com, za...@grossbart.com
I use spiffyui for free text search, and the input gets into the hash fragment, so I can't really avoid using "these characters" since they are legit in my app. Encoding doesn't help, and also putting setting spiffyui.History.enabled to false didn't help (with your latest push included). It works for you?

regards,
Milan

Zack Grossbart

unread,
May 16, 2013, 3:09:53 PM5/16/13
to spif...@googlegroups.com
Hello Milan,

I haven't had a chance to turn try turning off the history in your app, but
if that doesn't fix this issue then something else is going on. Disabling
history should disable all history interactions in the browser so that makes
me think there might be another cause to this issue. I'll need to debug
your application a little more and I probably won't get to that until early
next week.

You also might want to try the latest snapshot again. It looks like our
build server hadn't deployed the latest code yet. I just pushed out a new
snapshot manually.

-Zack

milan....@gmail.com

unread,
May 16, 2013, 3:15:15 PM5/16/13
to spif...@googlegroups.com, za...@grossbart.com
thanks again for the prompt reply! Btw I built the latest snapshot myself (commit 6973c033ef included). 

regards,
Milan

Zack Grossbart

unread,
May 16, 2013, 5:12:24 PM5/16/13
to spif...@googlegroups.com
Hello Milan,

I had a little time to track this down. It turned out that my suspicions
about history.js were correct. It is using that specific hashcode for
internal history maintenance. If you'd like them to change you might want
to file a bug with them.

https://github.com/browserstate/history.js/

In the mean time I've got a workaround for you. It turns out that there was
a bug in Spiffy UI. There was no way to actually turn off the history
integration. I've changed that, but that's not enough to fix this issue.
The key is to make sure you don't import history.js. The problem is that
file gets compressed into the spiffyui.min.js file.

The solution is to import the specific JavaScript files directly. I've
forked your project, made those changes, and made a pull request.

https://github.com/mbsimonovic/spiffyui-hash-bug/pull/1

This should work around the issue and makes your test case work well.

I hope this helps.

Good luck,

Milan Simonovic

unread,
May 16, 2013, 9:16:51 PM5/16/13
to spif...@googlegroups.com
Hi Zack,

you're right, excluding history.js works around the problem. Thanks again!

regards,
Milan

On May 16, 2013, at 11:12 PM, Zack Grossbart <za...@grossbart.com> wrote:

> Hello Milan,
>
Reply all
Reply to author
Forward
0 new messages