Community
Participate
Working Groups
Browser#computeSize(SWT.DEFAULT, SWT.DEFAULT, true) does not seem to care about the browser contents. Instead, it returns the current size of the browser. I would either expect to see this documented in Browser, or it should really compute the minimal size based on the browser's contents.
I would love to have this feature too. It should be very helpful if you could resize the browser to fit its content. For instance, when you have the browser as a form section control, section's scrollbar will appear when needed instead of the browser one. It isn't nice to have two scrollbars for the same piece of UI, one near the other.
Would be nice if this is possible: I would like to have html tooltips in SWT just like in Swing (how does Swing do it??). However the contents of my tooltips are dynamic so the height of the tooltip is not known in advance. For this it would already be useful if we can set a fixed width and have only the height calculated.
Increasing priority as I was told it was a blocker for some people. (language server info hoverbox of sort).
(In reply to Markus Keller from comment #0) > Browser#computeSize(SWT.DEFAULT, SWT.DEFAULT, true) does not seem to care > about the browser contents. Instead, it returns the current size of the > browser. > > I would either expect to see this documented in Browser, or it should really > compute the minimal size based on the browser's contents. Ok, so I've started giving this some thought. The problem that comes to mind is 'how do you compute the content size'. I mean not from a technical point of view, I mean theory wise. Html is designed to adapt to whatever size the renderer is at. How do I go about translating html into 'size' in a meaningful way? E.g: suppose we have: <body> Hello world. This is a very long line of text that can be on a single line or span across multiple lines depending on the width of the Browser. So should this be a wide & short browser or narrow & tall one? </body>. One possibility is to assume fixed width and height and see the minimum size required to fit a string into such a box. Or assume aspect ratio based on monitor resolution and do some math. (In reply to Henno Vermeulen from comment #2) > Would be nice if this is possible: I would like to have html tooltips in SWT > just like in Swing (how does Swing do it??). However the contents of my > tooltips are dynamic so the height of the tooltip is not known in advance. > > For this it would already be useful if we can set a fixed width and have > only the height calculated. That might not be a bad starting point. It would be quite helpful to have some hard examples, e.g sample broken snippets and their actual expected behavior. One should take into account that Browser isn't always used as a 'hover box' of sort, so we should probably try to make it more generic. Thoughts?
But suppose we find an algorithm that deals with sizes if we assume that there is only fixed width/height text. But another thing to consider is how to deal with variable size elements? E.g font sizes for headings, dynamic content, images scaled at different sizes, might take up more or less space. Webkit2 seems to have some DOM api to get font sizes, but there deosn't seem to be logic that would deal with size of images or other html content. I.e there isn't a way to tell sizes in the traditional way as we do with widgets. Html is very loose on this. I can't think of a meaningful way to implement this given the flexibility of html/javascript/css. A generic algorithm might work for a few corner cases, but it wouldn't work well across most other use cases. E.g, javadoc would favour wide and short boxes. A generic Browser would favour a particular width suitable for reading text and then make it higher or shorter depending on amount of content. Custom widgets (e.g rich style text in nebula) would yet favor something that would allow all of their icons to fit without wrapping. I.e, to determine a size, a higher level understanding of the content is sort of required. One approach for Browser users might be to consider monitor dimensions, or first populate a 'Text' and based on it's dimensions set the Browser widget to be of that height. But I'm open to suggestions. Please post your thoughts, maybe I"m missing something.
There is most likely something in SWT thay computes the size in order to draw the content and place scrollbars correctly in case size of receiver is too small. That internal size is what's expected. ComputeSize could do some offscreen/hidden rendering to compute the size as provided by the browser. I beleve SWT should absolutely *not* drill down at DOM level to compute anything. The min size of browser must be returned by the browser (webkit or whatever) directly, which is the only source of truth and which we don't want to replicate pieces of logic that are better as blackboxes.
(In reply to Mickael Istria from comment #6) > There is most likely something in SWT thay computes the size in order to > draw the content and place scrollbars correctly in case size of receiver is > too small. That internal size is what's expected. > ComputeSize could do some offscreen/hidden rendering to compute the size as > provided by the browser. > I beleve SWT should absolutely *not* drill down at DOM level to compute > anything. The min size of browser must be returned by the browser (webkit or > whatever) directly, which is the only source of truth and which we don't > want to replicate pieces of logic that are better as blackboxes. Would you be able to provide a simple snippet of what is not working. I could investigate and use that as a test to verify a fix.
I have a semi-workaround for this issue implemented here: https://git.eclipse.org/r/#/c/120954/1/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/hover/LSBasedHover.java By using the browser execute/evaluate functions you are able to take the following steps to get a good estimate for a reasonable layout size of browser content: - Set the whiteSpace of the page to nowrap - See what the width of the content would be without a max width constraint - Set the width to the less of either the max constraint or the max of the content - Set whiteSpace back to normal to have the content fit into the new width - Calculate the resulting height of the content with the set width You now have a height and width of the content.
Thanks for documenting this interesting workaround Lucas! @Leo and others: do you think this is the best approach? Or there could be a way to get the size of the rendered HTML directly from the Browser widget?
(In reply to Mickael Istria from comment #9) > Thanks for documenting this interesting workaround Lucas! > @Leo and others: do you think this is the best approach? Or there could be a > way to get the size of the rendered HTML directly from the Browser widget? WHO says it's a 'workaround'? It's a good solution :-). Me and Lucas were whiteboarding this thing and looked at webkit guts. There is no api to get the size of the what's inside the webkit renderer other than via javascript. So this mechanism of getting the inner size is quite feasible. @Lucas, would you consider implementing an SWT snippet that we can use as demonstration on our Snippet website? https://www.eclipse.org/swt/snippets/ Snippet 136 could be a good starting point: org.eclipse.swt.snippets.Snippet136 I.e, add a progressListener(), and on completion, get the page size and re-size browser to that size. wdyt?
(In reply to Leo Ufimtsev from comment #10) > WHO says it's a 'workaround'? > It's a good solution :-). typical user expctation is the one that's reported here, having Browser#computeSize(...) working, so everything else is a kind of workaround. Maybe it'd make sense to implement the computeSize method with this approach?
(In reply to Mickael Istria from comment #11) > (In reply to Leo Ufimtsev from comment #10) > > WHO says it's a 'workaround'? > > It's a good solution :-). > > typical user expctation is the one that's reported here, having > Browser#computeSize(...) working, so everything else is a kind of workaround. > Maybe it'd make sense to implement the computeSize method with this approach? There are some problems with this approach. 1) Conent size != browser size. We could have big/small content, but different size Browser. 2) The size is only proper after the content loads, where as for typical SWT widgets the size is proper as soon as the shell opens and layout was called. So one can't quite implement this without sort of breaking api. However, one option might be to implement a 'computeCurrentContentSize()' and clearly annotate that such method should only be used once page is loaded (e.g in/after a ProgressListener.completed event). wdyt?
> 1) Conent size != browser size. We could have big/small content, but > different size Browser. sed 's/Conent/Content/
New Gerrit change created: https://git.eclipse.org/r/121346
Gerrit change https://git.eclipse.org/r/121346 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=9f15aa7692178890d7c74e1e0ef79a329c36f9fa
New Gerrit change created: https://git.eclipse.org/r/121816
Gerrit change https://git.eclipse.org/r/121816 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/swt.git/commit/?id=1a76830560e2c9bf7ec3120b00a67f0d1101d3c5
For the time being we have the snippet to demonstrate how to implement this functionality. (Thank you Lucas for submission). There are some issues with turning this into API. I've outlined the details in a new bug submission: 534120 – [Browser] Add api to retrieve width and height required to render HTML page without scrolling. https://bugs.eclipse.org/bugs/show_bug.cgi?id=534120 Closing this for now. Please feel free to leave feedback in other bug or re-open if you have suggestions (considering issues outlined in this bug and the one above).
Changing status to wontfix as technically the 'computeSize()' api was not implemented. Instead moved to: 534120 – [Browser] Add api to retrieve width and height required to render HTML page without scrolling. https://bugs.eclipse.org/bugs/show_bug.cgi?id=534120
