Bug 558846 - SWT Browser.refresh should respect html text set via Browser.setText
Summary: SWT Browser.refresh should respect html text set via Browser.setText
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.15   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-06 11:10 EST by Jie Kang CLA
Modified: 2020-01-14 04:19 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jie Kang CLA 2020-01-06 11:10:16 EST
When a user sets the HTML text of the Browser widget via Browser.setText and then refreshes the page via Browser.refresh or the context menu Reload function, the Browser revisits the URL set, discarding the HTML text set earlier, for example, if no URL was set, the Browser shows a view of the file system.

I think the Browser should instead "reload" the current HTML text if set. If no text was set then revisiting the URL makes sense.
Comment 1 Alexander Kurtakov CLA 2020-01-10 07:25:32 EST
In the future please attach a plain SWT snippet to reproduce and debug the issue. I always pay more attention to such reports :)
Comment 2 Alexander Kurtakov CLA 2020-01-10 07:30:39 EST
I've tried with the following:
public static void main(String[] args) {
		Display display = new Display();
		Shell shell = new Shell(display);
		shell.setSize(500, 600);
		shell.setLayout(new FillLayout());

		final Browser browser = new Browser(shell, SWT.NONE);
		browser.setText("hello <b>world!</b>");
		browser.refresh();

		shell.open();
		while (!shell.isDisposed()) {
			if (!display.readAndDispatch())
				display.sleep();
		}
		display.dispose();
	}

but didn't manage to reproduce it. Please tweak it accordingly so it reproduces the issue.
Comment 3 Jie Kang CLA 2020-01-10 08:47:13 EST

I have created a reproducer, pasted below.

For your snippet, I think the timing of the calls makes the Browser not actually refresh, not sure on implementation details. If you manually reload your snippet via right-click -> "Reload", the behavior is exhibited.


	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Display display = new Display();
		Shell shell = new Shell(display);
		shell.setSize(500, 600);
		shell.setLayout(new FillLayout());

		final Browser browser = new Browser(shell, SWT.NONE);
		
		shell.open();	
		
		browser.setText("hello <b>world!</b>");
		browser.addProgressListener(new ProgressAdapter() {
			@Override
			public void completed(ProgressEvent event) {
				browser.removeProgressListener(this);
				browser.refresh();
			}
		});
		
		while (!shell.isDisposed()) {
			if (!display.readAndDispatch())
				display.sleep();
		}
		display.dispose();
	}
Comment 4 Alexander Kurtakov CLA 2020-01-10 10:31:42 EST
(In reply to Jie Kang from comment #3)
> 
> I have created a reproducer, pasted below.
> 
> For your snippet, I think the timing of the calls makes the Browser not
> actually refresh, not sure on implementation details. If you manually reload
> your snippet via right-click -> "Reload", the behavior is exhibited.
> 
> 
> 	public static void main(String[] args) {
> 		// TODO Auto-generated method stub
> 		Display display = new Display();
> 		Shell shell = new Shell(display);
> 		shell.setSize(500, 600);
> 		shell.setLayout(new FillLayout());
> 
> 		final Browser browser = new Browser(shell, SWT.NONE);
> 		
> 		shell.open();	
> 		
> 		browser.setText("hello <b>world!</b>");
> 		browser.addProgressListener(new ProgressAdapter() {
> 			@Override
> 			public void completed(ProgressEvent event) {
> 				browser.removeProgressListener(this);
> 				browser.refresh();
> 			}
> 		});
> 		
> 		while (!shell.isDisposed()) {
> 			if (!display.readAndDispatch())
> 				display.sleep();
> 		}
> 		display.dispose();
> 	}

Text is still displayed fine for me on Fedora 31(webkit2gtk3-2.26.2, gtk3-3.24.13) using SWT nightly. Can you try whether you can reproduce on F31?
Comment 5 Jie Kang CLA 2020-01-10 10:41:12 EST
Okay, I will try to get a F31 VM or desktop to test and reply back then.



For what it's worth, I am on F30 X11 (i3wm) with

webkit2gtk3-2.26.2
gtk3-3.24.11

org.eclipse.swt.gtk.linux.x86_64_3.113.0.v20191204-0601.jar
Comment 6 Jie Kang CLA 2020-01-10 10:44:38 EST
Also for what it's worth, the original bug for this is from Alex who says he is on Linux F31:

https://bugs.openjdk.java.net/browse/JMC-6663

I will still try to reproduce on F31.
Comment 7 Alexander Kurtakov CLA 2020-01-10 10:46:26 EST
(In reply to Jie Kang from comment #6)
> Also for what it's worth, the original bug for this is from Alex who says he
> is on Linux F31:
> 
> https://bugs.openjdk.java.net/browse/JMC-6663
> 
> I will still try to reproduce on F31.

Next thing is to try 4.15 I-build swt. We have ditched webkit1 support so we might have fixed some wrong code paths too.
Comment 8 Alexander Kurtakov CLA 2020-01-10 10:58:31 EST
Oops, I should stop work earlier on Fridays! I can reproduce and work on the issue next week.
Comment 9 Jie Kang CLA 2020-01-10 11:01:20 EST
Okay, no worries, please have a good weekend! Thank you for investigating this!
Comment 10 Alexander Kurtakov CLA 2020-01-13 14:56:04 EST
I have looked into it and I can add code in setText to set a boolean that it's custom html not from url and refresh to check it and if set to not to reload the page. That would fix the programatic case but the context menu reload comes from webkit so it won't be fixed that way. Still no idea how to fix that part.
Comment 11 Alexander Kurtakov CLA 2020-01-13 15:36:34 EST
(In reply to Alexander Kurtakov from comment #10)
> I have looked into it and I can add code in setText to set a boolean that
> it's custom html not from url and refresh to check it and if set to not to
> reload the page. That would fix the programatic case but the context menu
> reload comes from webkit so it won't be fixed that way. Still no idea how to
> fix that part.

I have reproduced that in plain C snippet so issue lays in webkitgtk. I'll report a bug.
Comment 12 Alexander Kurtakov CLA 2020-01-14 04:11:42 EST
Upstream webkitgtk bug https://bugzilla.redhat.com/show_bug.cgi?id=1546779
Comment 13 Alexander Kurtakov CLA 2020-01-14 04:12:35 EST
Real upstream bug https://bugs.webkit.org/show_bug.cgi?id=206217