Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Problem with fullscreen feature with Web Component/Shadow DOM #1677

Open
PCailly opened this issue Jul 17, 2019 · 19 comments
Open

Problem with fullscreen feature with Web Component/Shadow DOM #1677

PCailly opened this issue Jul 17, 2019 · 19 comments
Labels
bug

Comments

@PCailly
Copy link

PCailly commented Jul 17, 2019 •
edited by iangilman

I created a custom element using openseadragon
displayed in a <div>
works perfectly as long as do not move the Image
I can display Images sequences , collections
and zoom in and out,
but when move the image, it still works but is not displaye in the <div> anymore,
it seems that it is reinjected somewhere else and displayed "fullpage" in the browser.

The togglebutton works but getting back is a complete mess

Here is a test page ( Zoomify tab )

http://prenomsfrancais.free.fr/showcase/s0.html
@PCailly
Copy link
Author

PCailly commented Jul 17, 2019

The 'move' bug happens with
chrome opera an avast secure webbrowser not netscape
the 'fullpage' bug happens with all tested browser

@iangilman iangilman changed the title CustomElement Problem with full-screen feature with Web Component/Shadow DOM Jul 17, 2019
@iangilman iangilman added the bug label Jul 17, 2019
@iangilman iangilman changed the title Problem with full-screen feature with Web Component/Shadow DOM Problem with fullscreen feature with Web Component/Shadow DOM Jul 17, 2019
@iangilman
Copy link
Member

[I've updated the issue title to better reflect the issue, and I edited the description comment to fix the formatting.]

Yes, OpenSeadragon doesn't really support Web Components yet… I imagine there are a few things that need fixing to get it to work in that context.

The problem here, with full screen, probably has to do with the fact that for historical reasons, the full-screen mode actually moves things around in the DOM. More discussion here: #1127 and #1050.

Perhaps Web Components would be a reason to finally untangle the full-page mode from the full-screen mode. I'm not sure what to do on mobile platforms that don't have full screen; maybe disable full-page entirely for web components on those platforms?

Anyway, unfortunately it's probably not a trivial fix. I'm happy to point you in the right direction if you're interested in taking a whack at it, though.

@PCailly
Copy link
Author

PCailly commented Jul 18, 2019

In fact there are 2 bugs that have to do with Web Components ( that I know )
the 'Full Screen' and the 'Move' problems

I could solve the 'Full Screen' by not showing the Button ( How ?)
But the 'Move' Problem is more difficult.
It is still possible to move the image by zooming in and out to a certain zone of the image, and it could be sufficient for the moment, but is It possible to disable the move functionnality.

@iangilman
Copy link
Member

What do you mean by "move"? Are you talking about panning (dragging the image around)? That seems to work just fine. Are you referring to some other kind of "move" feature?

To disable the fullscreen button, include showFullPageControl: false in the options when you create your viewer.

@PCailly
Copy link
Author

PCailly commented Jul 19, 2019 via email

@iangilman
Copy link
Member

Oh, I see! I was testing on Mac Firefox, which doesn't have that problem. Mac Chrome does have it, though. It's very odd. My suggestion would be to try to isolate the conditions further. Clearly there's some browser specific weirdness happening.

One thing you might try is turning off OpenSeadragon mouse handling entirely:

viewer.setMouseNavEnabled(false);

...And see if it still happens.

@PCailly
Copy link
Author

PCailly commented Jul 20, 2019 via email

@iangilman
Copy link
Member

Ok, so now we know the "move issue" has something to do with the OSD mouse handling. We need to continue narrowing it down. If you use panHorizontal: false, panVertical: false in your options when you create the viewer, you can separate the mouse handling from the actual panning to see which it is that causes the issue.

Basically, we just need to narrow it down to find where the problem is; it's some combination of the OSD mouse handling plus certain browsers plus how you've set up your page (possibly having to do with the shadow DOM, but maybe having to do with other aspects).

One thing I'm noticing is that you're using flex and your pc-openseadragon element is height="100vh". That's likely to cause problems no matter what, since you're trying to fit more stuff than just that one element.

@PCailly
Copy link
Author

PCailly commented Jul 23, 2019 via email

@iangilman
Copy link
Member

Oh yes, sorry, lost track of the conversation.

I do think it probably comes down to the 100vh thing. Even if it does work in some browsers and some circumstances, it still seems like a hack (to me). I think the proper way to do that sort of thing with Flexbox is to have the tab panel and the combo box row have fixed heights and have the pc-openseadragon have flex-grow: 1.

Anyway, let me know if there's more I can be help with.

@PCailly
Copy link
Author

PCailly commented Jul 24, 2019 via email

@msalsbery
Copy link
Member

msalsbery commented Jul 24, 2019 •
edited

I agree that the 100vh trick is a hack

@PCailly

I don't understand what the "trick" is. To me all that does is obscure (off the bottom of the viewport) part of the 100vh height element. You can see this on an iPhone, for example, which lets you scroll your vertically-oversized viewport (100vh + the heights of the two header rows) into view.

For the issue, the only thing that "should" be happening when you click or zoom on the image is either the OpenSeadragon canvas "moves" (drag/pan), or in the case of a click, it zooms which increases the canvas size. Depending on the user agent and/or your CSS/styles, the OpenSeadragon canvas change may be displayed over the top of neighbor elements. Have you tried setting the OpenSeadragon containing DIV's overflow to hidden?

@msalsbery
Copy link
Member

msalsbery commented Jul 24, 2019 •
edited

@PCailly

For what it's worth, here's an example of what has worked well for me across user agents. Never used in shadow DOM though, but I would expect my user agent to handle it correctly because, as we all know, all browsers act the same ;-D

Note: The important thing here is the extra OpenSeadragon DIV with width and height 100%. The DIV with the class "viewer-container" would be your DIV that has a height 100vh. Using two DIVs, one with overflow:hidden and one with width/height 100%, seems to contain the OpenSeadragon viewer correctly across all browsers I've tested

	<div class="viewer-container">
		<div id="osd" class="openseadragon"></div>
	</div>

.viewer-container
{
	/*
	this really should be something like calc(100vh - 90px)
	so the DIV doesn't extend outside the viewport
	*/
	height: 100vh;
	overflow: hidden;
}

.openseadragon
{
	height: 100%;
	width: 100%;
}

	var viewer = OpenSeadragon({
		id: 'osd',
		...
	});

If there's dev tools with DOM element inspector available on the browser(s) it's not working in, you should be able to see what element is covering the header row elements. I'd bet it's the OpenSeadragon canvas...

@PCailly
Copy link
Author

PCailly commented Jul 25, 2019 via email

@msalsbery
Copy link
Member

@PCailly

Bummer. The example at the link is a good test...it’s broken on Safari iOS (the version yesterday had pointer events disabled). I’ll take a look and try to figure out what’s going on...

@iangilman
Copy link
Member

For what it's worth, I'm thinking something more like this:

<div class="page-content">
  <div class="top-nav"></div>
  <div class="openseadragon"></div>
</div>

.page-content {
  display: flex;
  flex-direction: column;
  width: 100vw;
  height: 100vh;
}

.top-nav {
  height: 20px;
  flex-shrink: 0;
}

.openseadragon {
  flex-grow: 1;
}

@PCailly
Copy link
Author

PCailly commented Jul 26, 2019 via email

@iangilman
Copy link
Member

I'm guessing the document.getElementById stuff is unrelated to the clicking issue, but who knows?

At any rate, it definitely should be sorted out for full shadow DOM support. I imagine some of it has to do with places where we will accept an ID or an element. Of course we need getElementById for the ID option, but anyone using the shadow DOM would need to use the element option. We just need to find places where you're forced into using getElementById and you have no other option.

Good to have these notes for whoever might take on this task!

@PCailly
Copy link
Author

PCailly commented Jul 27, 2019 via email

@iangilman iangilman mentioned this issue May 25, 2020
Closed
@JoernT JoernT mentioned this issue Mar 8, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@iangilman @msalsbery @PCailly