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.

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

In-course links in Notify content disable scrolling #1675

Closed
moloko opened this issue Jul 18, 2017 · 14 comments
Closed

In-course links in Notify content disable scrolling #1675

moloko opened this issue Jul 18, 2017 · 14 comments

Comments

@moloko
Copy link
Contributor

moloko commented Jul 18, 2017

If you include a hyperlink to another part of the course inside a Notify popup, the link works but scrolling is subsequently completely disabled.

This is presumably down to notifyView disabling scrolling when a Notify popup gets opened - but is not being given the chance to re-enable it again because clicking the link will cause Adapt to route to the new location without calling closeNotify.

Looking at the code I suspect this will also have an impact on accessibility, though I haven't tested that.

It seems reasonable to me that someone would want to add a link to another part of the course to a Notify popup - in this particular case it was to direct the user to a part of the course they needed to revisit because they'd answered a question incorrectly - so it would be great to get this working.

@danielstorey
Copy link
Member

Would something as simple as this work?

danielstorey@f1047f6

@oliverfoster
Copy link
Member

you just need to check the link target, a link going to a new window doesn't need to close the popup.

@oliverfoster
Copy link
Member

or re-enable scrolling on navigation?

@oliverfoster
Copy link
Member

oliverfoster commented Jul 19, 2017

or drop the disable scrolling behaviour? it is a bit rubbish (i know cos i wrote it).

@danielstorey
Copy link
Member

Lol. Returning to the same place does make sense. Like if you scroll when notify is open you could lose your place.

Close notify ensures that the notify class is removed from html as well as scrolling re-enabled.

See #1679

@tomgreenfield
Copy link
Contributor

I'd tend to agree with Ollie aiming more towards a re-enable-on-navigation-style approach.

Hardcoding an <a> tag event handler seems limited in scope, and also risky if you use an anchor for anything else within Notify.

You may have a button which performs Adapt.navigateToElement() on click, for example.

@danielstorey
Copy link
Member

Sounds fair Tom but all the handler does is calls closeNotify, which makes sure that notify closes, class is removed from html and scroll is re-enabled, on the condition that target !== "_blank".

I can't think of a use case where this behaviour would not be required. Notice that I have not called event.preventDefault meaning that as per your example Adapt.navigateToElement would still get called. This handler just ensures the other essential stuff happens as well :)

@moloko moloko mentioned this issue Jul 20, 2017
@moloko
Copy link
Contributor Author

moloko commented Jul 20, 2017

The only problem I can really think of with @danielstorey 's solution is that you might have an <a> in there (that doesn't have a target of _blank) where you wanted the Notify popup to be left open when clicked. struggling to think of a real-world example though!

If this is a concern then a possible alternative would be to require links or buttons to have some kind of attribute that flags that notify should be closed. I'd normally plump for a data attribute but I don't think those are easy to add via the AT.

Equally I'm happy to go with the solution as-is - and if we find it's not working out we can sort it out then.

@danielstorey
Copy link
Member

Bit hacky but could use classes instead of data attributes? Didn't know data attrs were difficult to add...

@moloko
Copy link
Contributor Author

moloko commented Jul 20, 2017

yeah you have to edit source to add data attrs which may be a bit much to ask

this is what you can add via the AT editor:
2017-07-20 15_48_11-adapt authoring tool

@tomgreenfield
Copy link
Contributor

A few possible use cases for anchors:

  • mailto links
  • links with download attribute
  • links which are used (hackily) to do an onclick action

To be honest, I was more worried about the bigger picture – if any navigation happens while in a Notify, you'll get the same frozen scrolling bug – <a> elements are just one way of triggering this. Try popping in a different ID in the URL while you're in a popup to test.

@danielstorey
Copy link
Member

Ok it's now sounding like the most sensible thing to do would be to call closeNotify when the route changes.

Something like this.listenTo(Adapt, "router:location", this.closeNotify);

How does that sound?

@oliverfoster
Copy link
Member

It's just a question of where you put it, where you remove the event listener and ensuring it only happens once. But yea, totally a better solution.

@danielstorey
Copy link
Member

Well thanks to Backbone listeners get removed with the view. I think this cracks it though.

b420a36

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants