z-index issue with WebViews and overlayed elements in newer NW.js versions
See original GitHub issueNWJS Version: 0.33.2 and 0.33.4 Operating System: Ubuntu 18.04 LTS
Expected behavior
Clicking anything in the modal should capture the mouse events (close modal, press action buttons, select text).
See image below:
Actual behavior
Clicking anything in the modal acts on the PDF (like it is on top) regardless rendering. Seems z-index
works for displaying the stacked elements correctly but not for input (mouse events).
How to reproduce
HTML markup:
<div class="container">
<webview src="://url/to/pdf"></webview>
<div class="backdrop">
<div class="modal">
<p>This is some text within a modal body.</p>
<button>Dismiss</button>
</div>
</div>
</div>
WebView and overlay styles:
.container {
position: relative;
}
.container webview {
bottom: 0;
left: 0;
position: absolute;
right: 0;
top: 0;
z-index: 10;
}
.container .backdrop {
background-color: rgba(0, 0, 0, .3);
bottom: 0;
left: 0;
position: absolute;
right: 0;
top: 0;
z-index: 20;
}
.container .modal {
position: absolute;
z-index: 30;
/* ...other modal styles... */
}
It was working properly with NW.js 0.30.2
and 0.31.0
versions. This behaviour was introduced after upgrading to newer NW.js versions. Is there anything related to plugins in frames/webviews that was changed in recent releases (like the Chromium PDF Viewer plugin)? Thanks!
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (1 by maintainers)
Top Results From Across the Web
nw.js: <Webview> does not appear, how to get it to show?
I am using nw.js to render the following index.html file which fails. Inspecting the element shows webview in the html code but it...
Read more > How to solve the Z-index issue Within 1 minute - DEV ...
We use Z-index with absolute or relative positions. When elements overlap, z-order determines which one covers the other.
Read more >webview Tag - NW.js Documentation
Use the <webview> tag to embed 'guest' content (such as web pages) in your app. Different from the <iframe> , the <webview> runs...
Read more >4 reasons your z-index isn't working (and how to fix it)
It seems simple at first- a higher z-index number means the element will be on top of elements with lower z-index numbers.
Read more >WebKit browser: Input elements disregard z ... - Issue Tracker
has a higher z-index than the static input elements on the page, touching ... but it still happening in all new versions of...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hello @rogerwang,
Thanks for pointing out. Tested with Chromium alone and it does reproduce the issue indeed.
Tested with the following Chromium versions:
Doesn’t work with Chromium 69 and 70. It works with version 72.
Uploaded a test case repository (basic Chrome App) for testing the scenario: https://github.com/cdog/chromium-webview-pdf-overlay
Expected result: Be able to click on “Test link” inside the overlay. Actual result: “Test link” is not clickable (with mentioned Chromium version 69 and 70).
Guess this will be fixed with newer releases of NW.js (by using newer Chromium builds).
@rogerwang sorry to comment on this issue again but I actually discovered the problem, attempting to have a frameless NWJS window broke things for me. So
is broken and
is fine. This only happened after upgrading from
v0.31.0
. Were there any changes that would have made this happen?