Nw.js: The webview tag is not sized properly

Created on 8 Jan 2016 · 17Comments · Source: nwjs/nw.js

Even if an explicit size has been declared, the webview tag is not sized properly when the application starts up. However, if the application's window is manually resized, then the webview immediately gets resized properly.

Here is an example page that triggers the problem:

<html>

    <head lang="en">
        <style>
            html, body {
                height: 100%;
                margin: 0;
            }
        </style>
    </head>

    <body>
        <webview src="http://google.com/" style="width:100%; height:100%;"></webview>
    </body>

</html>

When the application is launched the webview occupies roughly the height of a single line of text. The problem happens on Mac OS X Yosemite and Windows 8.1.

This is in NW.js 0.13beta2

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

P2 bug triaged

Source

djipco

👍4

Most helpful comment

For anyone else that happens to run into this issue, I found that in my case (using 0.19.5-sdk), it wouldn't change size unless I explicitly set the webview element's display style property to flex.

ie: <webview src="..." id="..." style="display:flex; height:100%; width:100%;"></webview>

jamespatrickwhite on 17 Jan 2017

👍4

All 17 comments

Try giving the webview a different display via CSS. Example: display: inline-block;

baconbrad on 22 Jan 2016

Take a look at #4229, you may have to use those styles for webview.

offshore on 25 Jan 2016

@offshore that doesn't solve the issue.

In addition to @cotejps bugreport I have noticed, that the webview.parentElement needs to be resized in order to size the webview property.

screen shot 2016-08-30 at 04 35 17

HaNdTriX on 30 Aug 2016

Try this (this is from the Electron documentation for the webview tag) http://electron.atom.io/docs/api/web-view-tag/#css-styling-notes

frankhale on 30 Aug 2016

close since it's a style issue.

rogerwang on 31 Aug 2016

@rogerwang this is not a real style issue. The answers above do not work because the styles won't get applied in this case.
The only thing that fixes the webview is a rerendering caused by its parentElement.

No chrome apps (with webviews) will work because of this issue. Cross compiling them to nw.js won't work. I have tested a variety of them.

Therefore the Chrome Webview API is not implemented properly.

Please reopen this issue.

HaNdTriX on 31 Aug 2016

ie: <webview src="..." id="..." style="display:flex; height:100%; width:100%;"></webview>

jamespatrickwhite on 17 Jan 2017

👍4

I can reproduce this issue on Linux/Windows with nwjs-sdk-v0.22.1.

Christywl on 8 May 2017

@Christywl the webview is a special tag and needs to be styled in a specific way to make it do what you want. I linked earlier the documentation that the Electron folks have mentioned about styling the webview. It works the same way in NW.js.

I've wrote an app that runs in NW.js and Electron and I use the same CSS to style my webview. In my case my webview needs to be the same size as the window and absolutely positioned:

#webview {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  z-index: 1000;
  display: inline-flex !important;
}

You may have other requirements so my snippet may not be what you need.

Here is the direct CSS styling information from the Electron docs:

CSS Styling Notes

Please note that the webview tag’s style uses display:flex; internally to ensure the child object element fills the full height and width of its webview container when used with traditional and flexbox layouts (since v0.36.11). Please do not overwrite the default display:flex; CSS property, unless specifying display:inline-flex; for inline layout.

webview has issues being hidden using the hidden attribute or using display: none;. It can cause unusual rendering behaviour within its child browserplugin object and the web page is reloaded, when the webview is un-hidden, as opposed to just becoming visible again. The recommended approach is to hide the webview using CSS by zeroing the width & height and allowing the element to shrink to the 0px dimensions via flex.

<style>
  webview {
    display:inline-flex;
    width:640px;
    height:480px;
  }
  webview.hide {
    flex: 0 1;
    width: 0px;
    height: 0px;
  }
</style>

frankhale on 8 May 2017

Hello@Frankhale, why do you need Z-Index? It is un-important
Please use it default:

        webview {
        position: absolute;
        top: 0;
        right: 0;
        bottom: 0;
        left: 0;
        width:100%;
        height:100%;
      }

It is not bug. I have tested and it works like real.

ghost on 8 May 2017

I use it in my app to make sure webview is higher than any other element. Yes it's not needed in the example, I was just pasting from my application.

frankhale on 8 May 2017

@frankhale , thanks for your advice. I tried again with the style above, the webview size is same as the window. So this is not a bug, right?
@cotejp , could you please double check in your test with the above advice?

Christywl on 9 May 2017

@Christywl I think the webview has special considerations that have to be taken when styling it like the Electron documentation says. What specific size requirements do you have with your webview? In my case I wanted the webview to occupy the entire size of the window and the CSS I mentioned above works well for both NW.js and Electron so I think the CSS styling requirements that the webview has are somewhat universal.

frankhale on 9 May 2017

@frankhale , thanks for your explanation. No specific case for me. I just want to confirm if it is a nwjs bug, if not, I want to close it.
@rogerwang , could you please help confirm this or should we add this CSS styling requirements in the webview in our docs?

Christywl on 9 May 2017

@cotejp , could you please double check in your test with the above advice?

I tried the above advice and it did solve my problem. In fact, modifying only the display property with display: inline-flex was enough to fix the issue.

I'm not sure why this works, what the implications are or what causes it but it should certainly be mentioned in the documentation because the fix is really not that obvious.

Thanks to all!

djipco on 9 May 2017

@boostio funded this issue with $15. Visit this issue on Issuehunt