Community
Participate
Working Groups
Build Identifier: I20091210-1301 Internal web browser has sometimes problem with refresh its content when open new page. Moreover this problem disappears when you click "refresh" button. I have observed such situation when IE8 installed but some people noticed on older versions of IE. Generally caching some content is normal behaviour of IE. When you try to open any site in IE and then open it in new window or tab you will get cached version. But when we are developing web application and want to test it, this action is inexpedient. Reproducible: Always Steps to Reproduce: 1. Create new dynamic web project and add index.html file in WebContent directory. 2. Right click on index.html file. Select "Run as -> Run on Server". You should see html file in your internal browser. 3. Modify index.html content. Select "Run as -> Run on Server" again. You get old content of file.
It is similar to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=298822 but in this bug I do not want to change SWT component but org.eclipse.ui.internal.browser.BrowserVeiwer behaviour
Please keep in mind bug 298822 comment 10. Actually, this bug is the exact duplicate of the bug 298822; I'd recommend to continue work in that bug as it contains some extra information.
I think the point of this request is for the Internal Web Browser View to not rely on the native browser's cache. SWT does not currently have api that allows a client to bypass the cache, this is what bug 298822 is now about. However even without this API, if a client really wanted to not rely on the cache they could do something like the lines below. browser.addProgressListener(new ProgressAdapter() { public void completed(ProgressEvent event) { browser.removeProgressListener(this); browser.refresh(); // <---- } }); browser.setUrl("http://..."); I'm not necessarily advocating for this change in the Internal Web Browser View, I'm just clarifying what the request is. I don't think the view should do this by default, but I suppose it could provide a second alternate 'Go...' button, or perhaps a view setting, that would ensure that a page's content is always reloaded for navigations.
Generally the problem is heavy in following situation: 1. Create new dynamic web project and add index.html file in WebContent directory. 2. Right click on index.html file. Select "Run as -> Run on Server". You should see html file in your internal browser. 3. Modify index.html content. Select "Run as -> Run on Server" again. You get old content of file. The easiest way to solve this problem is to add "Cache-Control: no-cache" header in setUrl() method. It is the best sollution for 3.6. Unfortuantely, method setUrl(url, postData, headers) appears only in SWT 3.6. In previous version the best sollution is method from Comment 3
Created attachment 156770 [details] patch-3.6 This patch adds "Cache-Control: no-cache" header in setUrl() method.
Adding the "Cache-Control: no-cache" definitely sounds like a better way for a client to accomplish this than comment 3. However I still suspect that for the Internal Web Browser View to offer this that it would want to provide a way for the user (or maybe the opener of the view?) to specify whether loaded pages should be cached or not, rather than never caching them.
I've been trying to reproduce this problem using slightly different steps but so far have not been able to reproduce it. I modified AboutServlet.java to add a counter to the page which would change every time it was refreshed. I then started the help system and opened http://127.0.0.1:2147/help/about.html in the Web browser view. Every time I hit refresh I got a new page. I have not tried the "run on server route" since I am less familiar with what the server is doing in that case. I am running Win XP with IE8. If I opened that same URL in two different tabs in IE8 I saw the exact same page, i.e. the counter was not incremented. I need to understand why I'm seeing refresh work correctly when you are not - is it because of a difference in where we are getting the page from. I'll attach a patch of the hack I made to the AboutServlet and perhaps you can see if you can reproduce my findings.
I think you should be repeatedly invoking setUrl() to the same url, not refresh().
Created attachment 156872 [details] Hack to about servet to use as a test case To test 1. checkout org.eclipse.help.webapp and apply patch 2. Start a new Eclipse Application 3. Set the help preferences to open help in an external browser. 4. Open the internal web browser view 5. Set the url in the view to http://127.0.0.1:<port>/help/about.html, you should see "Call 1" on the top line 6. Hit refresh If you keep seeing Call 1 the page is cached, if it goes to Call 2 it has been read from the server again. For me the counter is increasing every time I hit refresh.
Grant wrote: "I think you should be repeatedly invoking setUrl() to the same url, not refresh()." You're right, I need to read the bug report more carefully. Now I can reproduce the problem and it shows up if I open the web browser view, open a url, close the view then reopen it and enter the same url. It also shows if I type in a second url, open that page then reenter the first url and open it. If I just hit the open page button without changing the url it acts like a refresh.
I can also confirm that the patch fixes the problem. I think that preventing cacheing is an improvement over the current situation so I approve the fix if Grant is also OK with this approach.
My idea to patch to older versions of Eclipse is based on Comment 3. I am going to add progress listener when browser is IE. Do you have any comments or better ideas than my proposition? I know it does not like very good but I cannot find any better sollution. It solves use case from Comment 1 which I think is most common usage of WebBrowser in Eclipse.
If the patch is verified to fix the case then the patch is fine, it shouldn't cause a problem. The only thing that I think is worth considering is whether the view should be changed to always do this. My initial instinct is that it shouldn't, since my typical use of it is just for viewing typical on-line content. If it's more heavily used by apps that do web authoring, etc., then perhaps the change makes sense. I had assumed that such apps provided their own Browsers rather than using the Internal Web Browser view, but I've never actually used such an app to verify this. Anyways, you probably know what's best to do here based on the view's most typical use cases. Bypassing the cache doesn't hurt anyone, it just makes some page loads take longer.
re: comment 12 I think the only alternatives to calling refresh() are: - are you generating the page content being viewed? If so then it could include a tag like: <meta http-equiv="Pragma" content="no-cache"> (google this, there are various opinions about how well this works) - hack your swt to add the setUrl() api that takes the header arg (not generally advised)
Created attachment 157089 [details] patch-3.5 This patch refreshes web browser after loading url first time.
Created attachment 157090 [details] patch-3.4 Refreshes web browser after loading url first time.
Chris, could you review patches to 3.5 and 3.4?
I have committed the patch to HEAD so this is fixed for 3.6. I was not planning to make any fixes for 3.4 or 3.5, did you still need feedback on the patches?
Resolving as FIXED
I want to make sure I understand the suggested patch for 3.4 and 3.5. I see in the comment: // Feature in IE: IE caches Browser caches web pages and for // the same address display always the same page until not refreshed // See bug #300174 Should the word "not" be removed? As for how the patch works is this going to cause every page to be loaded twice? If so that would be a very high price to pay to fix a fail to refresh problem but maybe I am not understanding the patch.
Comment on attachment 157089 [details] patch-3.5 For 3.5 we will look at a different solution.
Comment on attachment 157090 [details] patch-3.4 For 3.4 we will look at a different solution.
Hello! One quick question. I downloaded an Eclipse Helios JEE build (Build id: 20100917-0705), and I still see that a cached version of a web page is shown in the internal web browser after the first "Run As-> Run On Server" action on a web page. Should the patch proposed disable cache in the internal web browser?. I followed the same "Steps to Reproduce" mentioned in the description of this bug and I still get the cached page as a result of the "Run On Server". Thanks Musa
Yes, the patch should have fixed the problem for Helios. I'm not sure why you are still seeing the issue. I will need to re test.
I was able to reproduce the problem using 3.7 M7. I am reopening this bug, I need to figure out what has changed since this was fixed.
Here are some instructions on how to reproduce the bug using only Eclipse. This tests refresh using a counter servlet in org.eclipse.ua.tests which contains a counter which is incremented every call. Check out org.eclipse.ua.tests from head into your workspace or import the bundle from the latest build. Launch a new run time workbench In the runtime workbench set the help preferences to open in an external browser Help/Help contents, note the url of help/index.jsp In the browser where help opened replace index.jsp with counter.html so you have a URL like http://127.0.0.1:49696/help/counter.html Open a web browser view Paste the url of counter.html into the web browser view Note the value of the counter Close the web browser view Open the web browser view again Paste the url of counter.html into the web browser view Expected result, the counter has been incremented. Actual result, the counter has not been implemented
Hi Grant, can you think of any reason why this would have regressed? I tested in a debugger and the patch which turns off cacheing is being taken.
The test steps don't work for me, when I invoke Help > Help Contents a bunch of exceptions are written to stdout like: javax.servlet.ServletException: java.lang.Error: Unresolved compilation problem: |?P_KEY_SHOW_SEARCH_DESCRIPTION cannot be resolved or is not a field| at org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:858) at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:791) at org.apache.jsp.advanced.searchToolbar_jsp._jspService(searchToolbar_jsp.java:93) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) I don't know why this would have stopped working. What are the arguments to the setUrl() call? Perhaps I can find a more basic case tomorrow with similar arguments.
(In reply to comment #28) > I don't know why this would have stopped working. Of course by "this" I meant the caching behaviour, not the exceptions I see.
I have no explanation for the exception you saw, I just tried in a clean workspace with the help plug projects checked out into my workspace and help opened fine for me. As for the cacheing problem it's possible that it was IE8 that changed, the problem is also present in Eclipse 3.6 and Eclipse 3.6.2.
Removing milestone - it does not look as though this is going to get fixed for Eclipse 3.7.
Created attachment 213232 [details] Patch for 3.7 Hi all, This is a patch for 3.7. Explanation: ------------- I did some debugging and found out that the proposed patch https://bugs.eclipse.org/bugs/attachment.cgi?id=156770 works for all IE browsers but not IE 8. Also I found out that the behavior in IE 8 is different. I could't find the root cause for this, as I'm not expert neither in IE 8 nor it's implementation in the Eclipse. Nevertheless I found interesting behavior related to a workaround that is being applied in the org/eclipse/swt/browser/IE.java The workaround itself works around IE bug http://support.microsoft.com/kb/320153 and works as follows: When a web resources is being requested and is about to be opened in the internal browser (IE), first the Eclipse makes a request to "about:blank" and then it makes the real request to the original resource. The proposed patch makes applying of this workaround conditionally. Till now, the workaround was applied unconditionally for all IE browsers. As this workaround has a side effect (makes bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=300174 to reappear), now it is applied only for IE version < 8. The fix works together with patch https://bugs.eclipse.org/bugs/attachment.cgi?id=156770 I tested it with IE 8, IE 7 (border cases) and it works. Could you please review this patch.
Thanks for investigating this Vladislav! I'm running with IE9 installed, and I've verified that IE.java's current workaround for http://support.microsoft.com/kb/320153 is still needed there (MS has not fixed their bug yet) and it is working. So comment 32 basically trades one buggy behaviour for another on IE versions >= 8, which I don't think is desirable. Your findings bring a couple of potential app-level workarounds to mind though. I know that workarounds are not ideal, but mentioning these could be useful in case a resolution for this is not found for 3.8: - If the problem only happens on the initial navigate then a ProgressListener can be added that invokes Browser.refresh() when ProgressListener.completed() is received (first navigate only). - If the problem you're seeing only happens with IE versions >= 8 then you can run in IE 7 emulation mode by setting a Java property as described in http://www.eclipse.org/swt/faq.php#browsernativeie (point #2).
Just for the record, this issue has regression only for IE 8.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
