How can I disable scrolling by touch on xterm.js?
I have a touchmove event on term.element that simulates cursor keys by swiping the appropriate direction. This works great in applications such as Midnight Commander that use the "alternate screen buffer", but in the default screen buffer that has scrollback (i.e. lynx or bash, for example), it scrolls the terminal (as it normally would) in addition to sending the ansi codes for the arrow keys.
I need to override this behaviour so scrolling does not happen when you swipe, without preventing scrolling by other means such as the mouse-wheel or the scrollbar, or interfering with other mouse events (and possibly touch events).
Tried preventDefault() on the event, even tried attaching it to various elements within the terminal, parentNode, and its parentNode. Same behaviour. Also tried position: absolute with bottom: 0px, but the way xterm.js simulates a terminal makes for abberant results.
Any ideas?
Ok. The solution is: add event.stopPropagation() at the top of the handler for the touchmove event. Attach it to the terminal element (i.e. term.element). Forget the overlay, pointer-events: none, etc. Works perfect. No additional garbage. I left in event.preventDefault() for another reason, but I think just the stopPropagation stands alone for this particular question.
I would like to add, if you just want to disable touch scrolling on the terminal all you need is:
term.addEventListener('touchmove',function(e){e.stopPropagation()});
Assuming your terminal object's name is 'term'.
Related
It seems to be a consistent browser behaviour that when the user drags out of a a element, to avoiding clicking on releasing the mouse button, that that element retains focus until the user clicks somewhere else.
Is there an accessibility related reason for this?
It seems to be a common user behaviour (interaction) to negate a click 'halfway through' and, in MacOS, at least, is the default menubar mouse behaviour.
I guess I'm looking for a way to force a drop of focus on mouseout but I don't know whether this is bad for accessibility.
Incidentally this is visually bad ugly either button is used as a UI object or an a is styled as a button.
Whether the focus remains on the button/link or if you force it away will not cause an accessibility issue with regards to WCAG conformance. It does not fail any guidelines.
It comes close to failing WCAG 3.2.2 On Focus but I think the timing of your events technically makes it pass. The mousedown event causes the focus event and you are not doing anything with the focus event. It's when the mouseup event happens that you're trying to move focus so in theory, you are not changing the context on the focus event.
I'm not sure that means you should do what you have proposed from a UX perspective but there probably aren't a lot of people that rely on the default behavior.
I've noticed that when I have long list elements in JQuery Mobile and I try to scroll them, I accidentally select an element. Overall the act of scrolling tends to get confused with tapping.
I did some comparison to a native iOS list and here is the difference:
In JQueryMobile, as long as you do a MouseDown and MouseUp on an element, it is considered a click. It doesn't matter if you've scrolled inbetween the events.
In iOS, if you do a MouseDown on an element and then scroll at all, the MouseDown is effectively canceled. This allows you to tap on something, scroll the page up and release without it being considered a click.
Has anyone noticed this and/or developed a patch for it? If not, any suggestions on a fix?
So my problem is that I have a TJvDocServerForm with an image inside, now all functionality works when its pinned, however when its unpinned and I try to use the mousewheel to zoom, the form hides straight after the zoom operation.
The zoom works through a scrollboxmousewheel event that triggers a
timer.
The timer then redraws the larger/smaller image through my own
image class when movement on the mousewheel has stopped.
Through break points it appears the draw is causing the form to
hide.
I believe this has got something to do with the focus being lost, however resetting the focus back to he form directly after the draw does not stop the hide as it has already been told to hide.
Is there a way to somehow lock the form from hiding until after the image has been redrawn?
This functionality (the unpinning thing) is rarely used. This code is extremely complex, and changing it is not recommended unless you like causing regressions. How common is the combination of mouse wheel + unpinning? So rare, I'd let it go, if I were you. If you can live without the unpin feature at all, just change dock styles. Personally I hate the unpinned state and I use a dock style that doesn't even support it. The unpinned "zoom away" animation may be directly linked to the focus-loss. You could store that state, wait until the next time through the message loop and then trigger the animation, if you wanted to, but even I, who have done lots of work in JvDocking source code, would be hesitant to try it.
I am working with the iPad (mobile safari):
Question:
Does anyone know how to hide the scrollbars on iPad?
I have looked already looked into webkit scrollbar styling using ::-webkit-scrollbar... This does not work for the main windows scrollbars.
Scenario:
I have an repeating image inside of a div that is over 10,000px by 10,000px. I want the user to be able to swipe the screen to move around over this huge div, which is essentially one big image, WITHOUT the scrollbars showing up.
So I need the functionality of the scrollbars, I just need them to be hidden.
Suggestions?
Thanks for your help!
-slwd
You might be able to use the TouchScroll library: http://uxebu.com/blog/2010/04/27/touchscroll-a-scrolling-layer-for-webkit-mobile/
Otherwise, what I would do is set overflow: hidden on your div and then use JavaScript to implement the scrolling. This will require listening for touchstart, touchmove, and touchend events, and moving the x/y position of your image accordingly. If you need frictional slowing (similar to what's built into scrolling views on mobile Safari) you can implement that as well. Keep track of the dx/dy between touchmove events, use that as a starting velocity for when you receive a touchend, then use setInterval as a timer to apply the friction until some minimum threshold at which you stop the animation.
This is sort of a hack, but: Make your UIWebView about 10px taller and wider than the screen.
(Inspired by someone asking the opposite question.)
Context: Web app on MobileSafari/iPad, both full-screen and embedded in iframe
Goal: Technique that provides custom event handlers for Press and Tap but not Pinch (zoom) or Drag (scroll/pan). We want to provide custom behavior for Press, but to let Safari handle Scroll/Pan/Zoom still.
Problem: The two goals seem to be mutually exclusive. To prevent the default behavior for a Press gesture, event.preventDefault must be called in immediate response to ontouchstart. However, to let the default behavior proceed on a Drag, we must not call event.preventDefault on the initial ontouchstart. Once preventDefault is called, there is no way of getting the default behavior back during that gesture sequence (i.e. until all fingers come off). Drag is not recognized until some movement has occurred.
Drag is illustrated as the simplest example, but we care about getting the default behavior for Pinch and Double-tap as well. We never want the default MobileSafari Press behavior of "Copy Image" or selecting text.
Attempts thus far:
Save the ontouchstart event and, after a timeout, call preventDefault on it later (just before Press would be recognized). No effect.
Listen for 'oncontextmenu'. Nope, the default Press behavior is not being signaled or routed through this event.
Prevent the default in all of our ontouch* handlers, and then when we recognize a Drag/Pinch gesture, simulate new events using initTouchEvent and/or initGestureEvent. The programmatically created events hit all of our callbacks, but Safari seems to pay no attention to them, triggering no default behavior.
Break up Safari's Press recognition with a fake move. Safari cancels a press on the slightest move, but we allow for a bit of slop. Simulating a move event (as above) just after the ontouchstart does not cause Safari to fail to recognize Press if the finger is not moved "for real".
We have a fully featured set of gesture recognizers implemented (in Javascript, ontouch*) in the style of Apple's native iOS gesture recognizers. We have no problem recognizing any gestures, we just don't know of a good way to replicate the Zoom/Pan/Double-tap behavior that Safari provides for free.
We don't need code; we're looking for any theoretical solution (beyond "just implement pan/zoom yourself too", though if you have a slick way of doing that we're interested) that leads to reasonable success. We're also interested in learning about other similar attempts to do this - surely we can't have been the first to try this?
Alternate TL;DR: Is there any way to prevent a default Press (also known as tap-and-hold) other than in touchstart?
Success: Prevent "default press" behavior entirely through CSS instead of preventDefault. This answer was provided by Safari Technologies Evangelist Vicki Murley over here (registration required)
I see in your stackoverflow post that
you say your ultimate goal is that:
"We never want the default
MobileSafari Press behavior of "Copy
Image" or selecting text."
These behaviors can be disabled in CSS
(+ one bonus property, since people
often want to turn off the highlight
if they're turning off these other
behaviors):
/* behavior */
-webkit-user-select: none; /* disable cut copy paste */
-webkit-touch-callout: none; /* disable callout, image save panel */
-webkit-tap-highlight-color: transparent; /* "turn off" link highlight */
Commentary: We assumed that Safari's Press behavior was event-based, not driven by CSS. Calling preventDefault ontouchstart does cancel the press behavior (which is what led us astray, really), but that seems to be an unintended side-effect. Really, Mobile Safari does not execute a "press event" so much as "CSS on press".
Disabling the Press behavior with CSS has allowed us to once again call preventDefault only where and when we actually need it.
Ugly Possibility: Don't prevent a press - make a default press do nothing. Try to use a glass-pane div that catches all touches and doesn't prevent anything on touchstart.
Divs do have default Press behavior (some kind of selection), but perhaps that can be turned off, not via preventDevault but via <body style="-webkit-user-select:none">? ref
This would mean we'd have to do our own hit-testing to determine what DOM nodes to pass our recognized events to, since we can't just let events bubble up the DOM ancestor chain.