I've asked this question on the GWT group with no luck, so now I'm trying Stack Overflow :)
There seems to be some problem with GWT's history and IE6 / 7, and I'm trying to confirm this is an actual problem with GWT and not just something stupid I've done.
The problem I run into is the following:
Imagine you have some GWT app that plugs in to your existing website. It has internal history and works fine. Let's just say it's a tree. What it is isn't important, just that it has state that you can go back and forwards in. Part of this app is links to other parts of your website. Click one of those and you exit the GWT application.
Now, use the "back" button after you've clicked one of these links. You return to the GWT application which loads fine and the state is recreated using whatever is in the URL.
If you the click back again, here's where I get differing results in IE6 / 7 and FF / Chrome / IE8. In IE6 / 7 this second "back" sends me to the page before the GWT app. In FF / Chrome / IE8 this second back sends me back in the state of the GWT app, which is what I want, naturally.
I've checked my code, and as far as I can see, this second "back" just goes directly to the page before. My history handler is never called, at any rate.
Has anyone else run into this? Or know of anywhere this problem is discussed? I've googled extensively with no results.
The GWT group is to noisy to get confirmations of potential bugs, it's mostly for beginners.
The approach I take when I start to assume that there is a bug in GWT, and after trying to get help from the GWT group, is to create an issue in the GWT issue tracker and cross posting in the GWT contributors group as well.
Here is the URL for creating an issue:
http://code.google.com/p/google-web-toolkit/issues/list
Make sure that you first search the issue list for possible duplicates.
I've not yet played with history in GWT since our apps are running in an IFrame and that just kills the possibility to implement history.
Related
I've a legacy app that features a DND from a popup window to the main one.
It works fine in IE 8 but not in any of the newer versions of IE. The effect results in the drag ghost image being stuck in the source window and not going away after the drop had occurred.
Some debugging did in fact confirm that the 'mouseup' event does not get propagated back to the source window. What can be done to fix it? Many thanks!
ITs a bit hard to begin to answer your question without some code....
use the File>Properties menu to find out which IE security zones the two windows(domains) map too...IE uses a different security model to other browsers... drag/drop is probably not allowed between local web files (using file: protocol) and internet or intranet sites.
Have you used the Dev tool yet to debug it? If you are using showModalDialog (which normally disables context menus) you can right click on a link (a) or input element to display the context menu so you can display the debugger for showModal content page.
If possible include a link to your website or a mashup (jsfiddle) with your questions.
When I try to implement a real time update system on my site, I usually make an ajax call, say every 5 secs to a processing file, say getUpdates.php (not sure if it's the right way to do). Get the updates from there and display it. Doing that, when I look at firebug or the developer tools in Chrome and Safari, I can see the file being called ever 5 secs in the XHR section of the tool; after which the updates are displayed.
In case of Google plus, twitter and Facebook, I don't see such a regular call although updates are appearing right in front of me.
How is it that they are doing or is it me not noticing such a regular call??
They use "Long polling" I think. Sounds like a fine excuse to dabble with node js if you ask me. :)
I've seen several posts about DropDownLists getting cleared, or events not getting fired, but they don't seem to match this situation.
I've got (well I've reduced the problem to) a very simple asp.net website, a master page with a content page. The content page has a single DropDownList with AutoPostback set to True. The code behind updates a Label with the list's selected value. Not using UpdatePanel or AJAX (though I tried using them and I get exactly the same results). It's an intranet site using Windows authentication.
It works fine on IE and Chrome, but every time I try it on my iPad it just sits and spins. The postback appears to be happening, but either nothing's coming back (or being accepted) from the server, or the client just doesn't know how to finish things up, or I don't know what.
Sorry if this seems vague but I've spent two hours on Google and haven't come up with anything other than the fact that a simple page like this should work fine on an iPad, so I'm a little punchy.
Anybody got any pointers or ideas?
EDIT: Running this page through the remote web access portal my company uses, it works fine. So this may be an authentication problem between the iPad and IIS.
Not sure I have an answer but do you have the issue if you remove the DropDownList? If you need to build the list based on data maybe you could use a asp:repeater and build a html select list.
I'm reading this google guide and using this sample code provided by google, but there's a glitch: using the back/forth buttons makes the URL change before the confirmation dialog has returned. This means that if the user decides not to navigate away, the URL no longer represents the current Place.
Anyone have a solution or workaround? Ideally, the URL would not change until the confirmation is given, but even just switching the URL back in a hurry after a denial would be better.
There's no workaround. Your app somehow detects that the URL has changed, which triggers the place change (thus before navigation is confirmed).
And there's no way to know why the URL changed; was it a "back"? a "forth"? a "back" using the history menu to go several steps back at a time? a bookmark? manual editing of the URL? So there's no way you could do a History.next() to "cancel" the URL change in all cases (also note that it would trigger another place change). And trying to modify the URL with anything else than History.back/next/go would erase the forward history, which you probably don't want either.
FYI, I implemented that behavior 2 years ago in my own "place manager", and talked about it with Ray Ryan when he added the PlaceHistoryHandler to GWT 2.1, and we agreed that there was no better behavior than letting the URL no longer being in sync with the place. FYI, when I studied the thing 2 years ago, and then earlier this year, GMail had the same behavior (create a draft message and navigate while the draft has unsaved changes).
What is the name of the IE plug in that someone can download (I think from Microsoft) that lets a developer (well, anyone who gets the plug-in, actually) to view the message traffic that goes on behind the scenes from the browser to the server? I saw this one in action but I forget its name. And I think, for the FireFox broswer, you can simply turn it on somehow without getting a plug in.
It cuts the browser window in half horizonally and the bottom half is also divided vertically and you can see the GET and POST messages as well as the complete header information that is sent to the server from the browser across the internet.
HttpWatch is a great plugin for IE, but it's not free. Microsoft also released a free tool called VRTA which works for all browsers, but isn't a plugin.
For firefox it's called Live HTTP Headers. Another option of course is WireShark.
Fiddler is from Microsoft.
http://fiddler2.com/fiddler2/