| Summary: | [Tree] Not well refreshed/redrawn when content is changed from a different perspective in IE | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Seif Gouta <sgouta2> |
| Component: | JFace | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | swimmer_86, tbuschto |
| Version: | unspecified | ||
| Target Milestone: | 1.5 M3 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Seif Gouta
Created attachment 206226 [details]
Before deleting the node zzz
Both views in perspective 1 and Adnmin perspective are using the same content provider. One node is removed from the content provider in Admin perspective. When going back to perspective 1 the node is gone but the icon remains there.
Created attachment 206228 [details]
After deleting node in content provider from Admin perspective then switching to Perspective 1
The node is gone but the icon remains, you cannot click on that node, it's a redraw failure.
Could you provide a complete self-running snippet/project that demonstrate the issue? BTW... It does not work *only* in IE and internal Eclipse browser (which uses IE core too under Windows). Isn't it? Chrome and Firefox work fine? Yes for the last question, the only place it works on are Chrome and Firefox, (since they use the same core than it explains why they are not running). I hope I will be able to reproduce it in a smaller code snippet/project. Could you try to run your code against the latest nightly build? We switched IE9 to use "standard" rendering instead of "quirks" - see bug 270397. Does it make any difference? Created attachment 206276 [details]
A simple 2 perspective application - From a modified version of the RAP mailbox demo
When application starts it will show the RAP perspective. Go to "My perspective", click the big button to update tree views with a new smaller data. Notive how the tree item "Send" will be removed. Go back to RAP perspective and the "Send" tree item will be gone but the icon will remain, it's a rendering issue, you won't be able to click on the icon.
Hello Ivan! I have tried and the problem persisted. Thanks (In reply to comment #6) > Could you try to run your code against the latest nightly build? We switched > IE9 to use "standard" rendering instead of "quirks" - see bug 270397. Does it > make any difference? Comment on attachment 206276 [details]
A simple 2 perspective application - From a modified version of the RAP mailbox demo
NavigationView2 in the second perspective has a button that modifies the data for the treeviewers in both perspectives. It also refreshes the treeviewers. DataManager is a singleton that holds the first treeviewer and 2 models just as a means to communicate between the two perspectives.
In RAP 1.5 it seems to work. (In reply to comment #8) > Hello Ivan! I have tried and the problem persisted. Thanks Same as Tim, I can't reproduce it with the latest nightly build (CVS HEAD). Tested both external IE9 and internal Eclipse browser. Could you check it again? Ok, I tried today's Composite Artifact Repository - http://download.eclipse.org/rt/rap/1.5/runtime and it still didn't work because I thought it was the latest build, but as you said Ivan the latest night build solves the problem, I found the link in wiki. Thank you very much! OK... this means that "standard" rendering in IE9 fixes the problem. Nevertheless, the problem is still reproducible by me with IE8 (Windows XP). Fixed in CVS HEAD, TreeRow.js#_ieFixLayoutOnAppear. *** Bug 363682 has been marked as a duplicate of this bug. *** These fixes are applied for RAP 1.5. Is there any way to port them into RAP 1.4? Regards, Yury. Check this fix in RAP 1.4:
TreeRow.js#_hideRemainingElements : function() {
var node = this._getTargetNode();
for( var i = this._usedNodes; i < node.childNodes.length; i++ ) {
node.childNodes[ i ].style.display = "";
node.childNodes[ i ].style.display = "none";
}
}
It works in FF8.0 and IE9.
Regards,
Yury.
*** Bug 363682 has been marked as a duplicate of this bug. *** |