URL's hash disappears when opening a ComboBoxItem with document click handler

[PhoenixClearwater]

1. Using SmartGWT 4.0 (patched 20140401) and SmartClient Version: v9.0p_2014-04-01/LGPL Development Only (built 2014-04-01)

2. IE10 (neither FF nor Chrome appear to be affected).

3. No logged errors either client or server side.

4. Sample code attached.

I've tried to boil my attached code down to the most basic situation I could get the issue to be reproducible. Unfortunately, I wasn't able to isolate the issue in such a way that it would present when running in Native Mode. That means the code will only show the issue in Hosted Mode. However, my main application where I discovered this issue was reproducing in Native Mode.

The basic issue is that: when I click on a ComboBoxItem's arrow to open the results my "window.location.hash" value clears out. This only seems to happen when I have a click handler attached to the document. I noticed in my test case it was also dependent on the event handler function being wrapped in the $entry() method (which I do need because in practice I will be calling back into GWT). The handler doesn't have to do anything, it just has to be attached. I can fix the issue without any side-effects by calling jQuery's preventDefault() method on the event, but I'm not sure yet if there will be no further issue or not so I wanted to at least document the issue.

To reproduce with the attached code:
1. Make sure your app includes jQuery (1.7.2 was the version we tested with)
2. Load the page
3. Change the url to something that has a hash value (e.g. #temp)
4. Click on the ComboBoxItem's down arrow
5. Notice only the "#" remains but not "temp"

[Isomorphic]

Do you have GWT's History capability enabled? We have seen some weird interactions with GWT History and JQuery.

[PhoenixClearwater]

Yes, we do. That is why this issue was kind of prevalent for me. I would click a ComboBoxItem and the change pages because of the History listener.

[Isomorphic]

OK, from what we know, the interaction creating an issue for you is a problem between JQuery and GWT History; SmartGWT as such is not really involved except that it happens to create some HTML that involves an anchor(<a> tag), and these two other systems seem to have conflicting handling for this.

Sorry we can't be of more help, but if you isolate it, other users would probably thank you for sharing any information.

[PhoenixClearwater]

Interesting. If you could be more specific as to which anchor tag is causing the issue I would definitely like to dig into the issue some more one day. For now I'm going to have to move forward with my preventDefault() fix however.

Also, if it makes much of a difference: I was not able to reproduce the behavior I described unless I specifically clicked on the down arrow of the ComboBoxItem. I tried clicking on datepickers, buttons, windows, a native menu system we have, and nothing happened with any of them.

[Isomorphic]

Curiouser and curiouser.

In your app do you see any difference in the HTML between that down button and other similar controls (FormItemIcons) that don't trigger a problem?

There shouldn't be a difference, but evidently for you there is..

[PhoenixClearwater]

I should probably go ahead and test with some other similar controls, but for now I've attached screenshots of my IE dom for at least two items I've tested (PNGs uploaded as TXT files, sorry for having to work around the system and not just putting the html in an html file...). The first is obviously the ComboBoxItem's down arrow and it has what I'm assuming is that anchor tag you were talking about. The second is a IButton which is positioned via an HStack next to the ComboBoxItem's DynamicForm. It does not have any anchor tags.

[Isomorphic]

To clarify, it's not surprising that a ComboBoxItem has an anchor tag and a Button doesn't - that's expected. What's surprising is the claim that ComboBoxItem behaves differently from other formItemIcons, which also have anchor tags. Are you actually seeing that?

[PhoenixClearwater]

No, I'm not seeing that. I apologize if that was the impression I gave. The only FormItem I tested (and therefore the only thing with a FormItemIcon I'm assuming) was ComboBoxItem. At the time I didn't know the anchor tag you were referring to was in the FormItemIcons. That makes sense why ComboBoxItem would have the issue and nothing else I was working with though.

If I get the time to look into what is happening with that anchor I'll definitely post some details back here. For now, all I can say is that I definitely see why that anchor is an issue. It has an href="#" attribute. Now, why adding a document click handler causes that href to actually be followed I'm not entirely sure. I can only assume it's because the click on the link bubbles up to the document and doesn't get prevented along the way. Which would explain why preventDefault() fixes the issue. I'm definitely glad the event bubbles because it makes what I'm trying to do possible, but at the same time I'm surprised that however you guys prevent the default action from taking place doesn't play well with jQuery.

[Isomorphic]

Remember, this problem is specific to JQuery + GWT History as far as we know. We don't seem to have problems with JQuery alone, or with GWT History alone.

As a shot in the dark, you might be using RootPanel.add() to add our widgets to the DOM. If you use draw() instead, which we recommend in general, you might be able to get GWT to stop interfering with our DOM (which it doesn't understand).

Note that the href is there because it's necessary in order to allow the icon to get keyboard focus. So its presence is both intended and necessary.