Can't scroll up while using drag and drop

Submitted by M300 on Fri, 08/30/2019 - 15:09
Forums: 
Bugs in content types

When using mobile and tablet users can't scroll up to place words in there correct slot - please fix this bug. We need auto scrolling!

BV52's picture

BV52

Fri, 08/30/2019 - 21:03

Hi M300,

Thank you for reporting this. There is an existing bug report and you can follow the progress here.

-BV52

riiko

Thu, 02/06/2020 - 16:07

Hi, having the same problem with mobile screens, words are bottom of a text field and it's not possible to drag them 

Could one possible (easier?) solution be a word area that floats on top of the text area in smaller screens? 
(Have to position it so that it does not cover the Check the answer button so top of the screen position might be better)

Drag the words h5p content bug

 

Attachments: 
Image icon drag_words_float.png
BV52's picture

BV52

Thu, 02/06/2020 - 18:17

Hi riiko,

Thank you for the suggestion although if I'm not mistaken this is more work code wise comapred to fixing the existing bug.

-BV

mcaptref

Mon, 10/12/2020 - 04:49

Hi BV

I've just started using H5P for my elearning course and needless to say I'm absolutely loving it so far.

However, I've just encountered this problem myself on my mobile device - the draggables at the bottom of the screen simply will not drag/scroll upwards - rendering the activity virtually useless on mobile devices. This seems to be a well documented issue spanning a number of years. Do you know if there has been a fix at all?

Many thanks!

otacke's picture

otacke

Mon, 10/12/2020 - 07:37

Hi all!

That issue is impacting multiple content types and is documented in https://h5ptechnology.atlassian.net/browse/HFP-1734.

I assume that the problem is H5P's iframe which is all the draggables know, so they don't know that the page should scroll. This could be fixed quite easily by retrieving the vertical position of the iframe and checking whether the draggable is about to hit the window's inner width boundaries - for local content at least. If content is embedded, it can't ask the outer window about the iframe position or the window's inner dimensions however. A solution would probably require probably require some amendmends to H5P core to add a function for triggering scrolling by content types and to the resizer.js script or another script that would have to be passed alongside the iframe source. It doesn't feel elegant to do it that way, so maybe someone else has a better proposal?

Best,
Oliver

atouloumtzidis

Thu, 02/17/2022 - 20:41

You couldnt just make tje h5p-drag-draggables-container  position:sticky;

with some css? This wont work?

 

 

otacke's picture

otacke

Sun, 02/13/2022 - 20:29

What do you think it would stick to?

atouloumtzidis

Thu, 02/17/2022 - 20:40

I thought it would stick at the top of the H5P container. Like this: https://www.digitalocean.com/community/tutorials/css-position-sticky

But it was just a guess. My competence with css is no more then "copy and paste" ...

atouloumtzidis

Thu, 02/17/2022 - 20:41

I thought it would stick at the top of the H5P container. Like this: https://www.digitalocean.com/community/tutorials/css-position-sticky

But it was just a guess. My competence with css is no more then "copy and paste"

otacke's picture

otacke

Fri, 02/18/2022 - 16:46

It can be made stick at the top if the iframe (H5P container), but it's the page that scrolls up and down and the iframe with it, not the iframe content.

atouloumtzidis

Fri, 02/18/2022 - 17:28

Well... that makes sense and is probably the reason, why it didnt work out for me ;)

And if i make the Iframe/iframe "scrollable"... nahhh maybe someone smarter then me must solve this problem....