Community
Participate
Working Groups
The first time the intro is opened, both the "Home" and "Back" navigation buttons are enabled. Selecting "Back" just reloads the home page, since I haven't visited any other pages yet. After the intro is initially loaded, if I browse to a new page and then hit "back" to return to the previous page, I don't actually go back (I remain on the current page). Also, the "Forward" button is suddenly enabled, even though it shouldn't be since I haven't actually left the current page. I have to hit "Back" a second time in order to truly get back to the previous page.
reproduced with RC4 :( regression bug. Im investigating.
This is a regression bug introduced by a change of behavior in the SWT Browser. It seems to have been introduced in RC3. Browser.setText() used to fire one navigation event, with url = "about:blank", and then display the in memory text. Now, it fires one more navigation event before the blank one. url = res://C:\WINDOWS\System32\shdoclc.dll/navcancl.htm This url was being treated as a regular url and so it was cached in the history of CustomizableIntroPart. The fix is to filter out urls with no protocol. patch forthcoming...
adding Chris for confirmation of change of behavior... Chris.. can you please confirm change of behavior. thanks
Created attachment 12814 [details] fix for setText events
I verified that the patch works.
I hope this doesn't filter out file:///, if so will cause us some problems when using static HTML pages from the filesystem?
In response to comment 3 The change of behaviour on Windows is the result of the fix for bug 66813 (calling setText twice) v>20040617. setText now requests IE to stop any previous network requests. This can cause IE to go to this URL before rendering the HTML in memory. res://C:\WINDOWS\System32\shdoclc.dll/navcancl.htm
Will this patch have a problem with other non-IE browsers?
In response to Lorne's comment #6, 'file' is a valid protocol, so it should not be affected by this. Mazen, am I correct?
Fixed.
I just read these updates... In response to comment 7 : thanks Chris.. I never got a chance to verify the defect because I actually worked around it, and your response got burried in my emails ! In response to comment 6 : yes we are broken.. but the patch will not affect this defect for now since we are broken. Just to clairfy: what is broken is the following scenario: navigating to a static html page from a dynamic page works. Navigate back works. Now navigate forward to the html page again fails. History skips page. This can be addressed in a fixpack. In response to comment 9 : Absolutely Dejan. file _is_ a protocol.. but setting the url in the SWT browser to file:///c:\test.html gives you a url navigation event without the file protocol. This is actually the cause of our defect above. This is defect 59497 to which I opened a defect 66887 and it fell through the Intro audits !!
Are you building your custom history list based on URLs received from LocationListener.changing events? If so, have you tried building the intro history list based on LocationListener.changed events instead? LocationListener.changing is mostly for filtering and blocking navigation before they happen. They can represent navigation requests that never complete and should not be part of a history. LocationListener.changed is fired after the navigation to that new location was successful - this is the right place to update the back/forward buttons. res://C:\WINDOWS\System32\shdoclc.dll/navcancl.htm is emitted in LocationListener.changing, but not in LocationListener.changed on the windows systems I have been testing. Building the history on the LocationListener.changed notification is preferable. If it is not in your case, let me know. I can't judge if this is a safer change at this point for tonight's build.
This may very well be the right way but we don't have any runaway to test possible issues so I would rather that we keep the workaround for now and try to use 'changed' in a fixpack.
Chris, yes, the history list is being updated based on urls Im getting from the changing event. Using the changed event will most probably solve this defect, but it will introduce another defect in the way the intro code today handles navigating to an html page that has frames. The Intro code today does use a flag to filter out events genereted due to frame navigation. A LocationListener sets the flag to true to indicate the begining of the navigation. A ProgressListener sets this flag to false on a completed event. This was the only handshaking that I can think of at the time to filter out all frames nicely. This logic will be broken if we use the changed event, and even if we do fix it and use changed, we would still need this flag trick. (ps: please let me know if there is a more proper way of filtering redundant navigations. As for the real remaing defect, which is not getting a protocol from the url passed by the location listerner, this also would not be solved by using changed event as the url is still without a protocol. I can most probably work around this problem and we'll address this in defect 66887 , but I need to know that having no protocol is the proper design. I didint want to work around a defect. this defect is closed. ps: discussion continues in defect 6687
ps: discussion continues in bug 66887
just to clarify the part of comment 11 which was a response to comment 6 :) "what is broken is the following scenario: navigating to a static html page from a dynamic page works. Navigate back works. Now navigate forward to the html page again fails. History skips page. " It seems that more is broken than this. With the patch applied, if you browse immediately from a dynamic page to a static page, you are stuck there permanently. You can't go back, you can't go forward, and you can't go home (the home button doesn't do anything). You have to close the intro and re-open it. To test this, run the the intro.samples intro from twix, and click on the "Static page sample" when the intro comes up.
