[webkit-dev] Selection Highlight for Canvas Rendering Object on Mobile Platforms?
I'm not sure this is exactly the right place to start, but I'll start here since the intersection of Andriod, iOS, and other developers are here. I've been testing some ideas for using the HTML5 canvas on mobile platforms versus desktop and I've notice an annoying feature on the mobile platforms. It is most noticeable on Android but also shows up on iOS on the iPad or iPod touch devices. The application involves the use of a HTML5 canvas that intercepts touch events on the canvas. Areas of a geometric image changes shading when touched to represent fractions of the object. On both platforms, there seems to be something about focus from the touch even that causes a highlight for the whole box containing the canvas element. On iOS, a gray shaded version of the canvas shows up for a very, very short period of time. It is inconsistent and depends how long the touch gesture is on the canvas. Some very short touch gestures do now cause the highlight of the canvas. That may be because it is just too short of a period of time to draw the highlight. On Andriod, any touch gesture cases a border and highlight around the canvas. Both are undesired effects. I'm trying to understand why the canvas has special highlight features for touch gestures over any other rendering object. Looking at the code, the highlight seems to be from the fact that RenderHTMLCanvas inherits from RenderReplaced just like RenderImage does. It all seems to key off of whether the canvas is selected. But the highlight isn't there for mouse clicks on desktop platforms. None of the CSS tricks (e.g. -webkit-user-select: none) seem to help on mobile platforms. It seems to me that on touch-enabled platforms (e.g. mobile) you should be able to disable this selection highlight behavior for canvas somehow. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] selecting text ignores mouse down position
The simple layout test below demonstrates that when you select text by
clicking and dragging, we ignore the position of the initial mouse
down and instead rely on mouse move events to judge what text is
selected. I verified the behavior on Linux (Chrome) and Mac
(non-Chrome).
Is it expected that the platform sends a mouse move event at the
position of the initial mouse down when dragging?
Or is this a bug in WebKit? I'm trying to figure out which layer I
should fix this at.
I manually verified on Chrome Linux via some logging statements that
if I move the mouse rapidly and drag, the mouse down position is
sometimes a pixel away from the first mouse move event position.
div id='text'The first part of this text should be selected./div
script
if (window.eventSender) {
var div = document.getElementById('text');
var x = div.offsetLeft + 1;
var y = div.offsetTop + 5;
eventSender.mouseMoveTo(x, y);
eventSender.mouseDown();
// With this mouse move event, we select the initial range of text.
// Without it, we don't -- we just get the caret positioned within the text.
eventSender.mouseMoveTo(x, y);
eventSender.mouseMoveTo(x + 50, y);
eventSender.mouseUp();
}
/script
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] selecting text ignores mouse down position
I think this is a WebKit bug indeed. I've been annoyed by this bug quite
few times and have been trying to figure out the reason. Thanks for
spotting the root cause!
- Ryosuke
On Fri, Mar 11, 2011 at 11:34 AM, Evan Martin e...@chromium.org wrote:
The simple layout test below demonstrates that when you select text by
clicking and dragging, we ignore the position of the initial mouse
down and instead rely on mouse move events to judge what text is
selected. I verified the behavior on Linux (Chrome) and Mac
(non-Chrome).
Is it expected that the platform sends a mouse move event at the
position of the initial mouse down when dragging?
Or is this a bug in WebKit? I'm trying to figure out which layer I
should fix this at.
I manually verified on Chrome Linux via some logging statements that
if I move the mouse rapidly and drag, the mouse down position is
sometimes a pixel away from the first mouse move event position.
div id='text'The first part of this text should be selected./div
script
if (window.eventSender) {
var div = document.getElementById('text');
var x = div.offsetLeft + 1;
var y = div.offsetTop + 5;
eventSender.mouseMoveTo(x, y);
eventSender.mouseDown();
// With this mouse move event, we select the initial range of text.
// Without it, we don't -- we just get the caret positioned within the
text.
eventSender.mouseMoveTo(x, y);
eventSender.mouseMoveTo(x + 50, y);
eventSender.mouseUp();
}
/script
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Considering a Touchhover
On Fri, Mar 11, 2011 at 6:43 PM, Charles Pritchard ch...@jumis.com wrote: Recently, while working on code review / accessibility for a large canvas application, I found that the iOS VoiceOver AT does not play well with the html canvas element. It can work, but it's not a natural transition from html to canvas (with buttons in it). Using transparent [button] tags work, but it is rather awkward. It occurred to me that, when VoiceOver is on, on these mobile devices, that a new touch type is active. For the time being, I'm proposing calling it touchhover. I do not know much about accessibility, but I think TouchHover would be a bad name for something not related to touch. Some touchscreen give information when a surface is hover the screen but have not touched yet. If this become mainstream for some reason, the name TouchHover might be the natural way to name this kind of events. cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] selecting text ignores mouse down position
For those following at home, this moved to
https://bugs.webkit.org/show_bug.cgi?id=56213
On Fri, Mar 11, 2011 at 11:39 AM, Ryosuke Niwa rn...@webkit.org wrote:
I think this is a WebKit bug indeed. I've been annoyed by this bug quite
few times and have been trying to figure out the reason. Thanks for
spotting the root cause!
- Ryosuke
On Fri, Mar 11, 2011 at 11:34 AM, Evan Martin e...@chromium.org wrote:
The simple layout test below demonstrates that when you select text by
clicking and dragging, we ignore the position of the initial mouse
down and instead rely on mouse move events to judge what text is
selected. I verified the behavior on Linux (Chrome) and Mac
(non-Chrome).
Is it expected that the platform sends a mouse move event at the
position of the initial mouse down when dragging?
Or is this a bug in WebKit? I'm trying to figure out which layer I
should fix this at.
I manually verified on Chrome Linux via some logging statements that
if I move the mouse rapidly and drag, the mouse down position is
sometimes a pixel away from the first mouse move event position.
div id='text'The first part of this text should be selected./div
script
if (window.eventSender) {
var div = document.getElementById('text');
var x = div.offsetLeft + 1;
var y = div.offsetTop + 5;
eventSender.mouseMoveTo(x, y);
eventSender.mouseDown();
// With this mouse move event, we select the initial range of text.
// Without it, we don't -- we just get the caret positioned within the
text.
eventSender.mouseMoveTo(x, y);
eventSender.mouseMoveTo(x + 50, y);
eventSender.mouseUp();
}
/script
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit handling of plug-ins out-of-process on the mac
On Mar 10, 2011, at 10:22 AM, Rudi Sherry wrote: One of the specifics is: is there a separate process for each object/document controlled by a given plug-in, or are all objects controlled by that plug-in in the same extra process, or is it a mix? All instances of the same plug-in will be in a single process; if you have two browser windows open with a Flash plug-in in each window, they'll both run in the same process. If you have a page with two different plug-in types (QT and Flash for example), they will each be in a separate process. - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Considering a Touchhover
There's no established API to handle this, but we are working on a W3C proposal http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html to address this. In the meantime, VoiceOver on iOS will call .focus() every time it hovers on an item, so you can use that monitor where VO is at any moment. If that doesn't work with canvas tags please file bugs at bugs.webkit.org and CC me On Mar 11, 2011, at 9:43 AM, Charles Pritchard wrote: Recently, while working on code review / accessibility for a large canvas application, I found that the iOS VoiceOver AT does not play well with the html canvas element. It can work, but it's not a natural transition from html to canvas (with buttons in it). Using transparent [button] tags work, but it is rather awkward. It occurred to me that, when VoiceOver is on, on these mobile devices, that a new touch type is active. For the time being, I'm proposing calling it touchhover. Currently, VoiceOver AT captures touch events, waiting until the user has set virtual focus to an element, then tapped twice, to set event focus on that element. It works quite well for html elements. My thinking is that this state, where it's not passing touchstart/touchmove/touchend events, is very much like the traditional hover events we've used with mice. If touchhover events were passed through Mobile Safari, I'd be able to use hit detection on canvas elements, and set the canvas element to the appropriate title matching whatever the user has focus upon. Does this make sense? Should I provide more examples? The purpose here is to enable UI elements in Canvas to work appropriately with touch-based AT, such as the iOS VoiceOver extension. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection Highlight for Canvas Rendering Object on Mobile Platforms?
-webkit-tap-highlight-color: transparent is what you need I suspect (at least for iOS). dave (hy...@apple.com) On Mar 11, 2011, at 10:33 AM, Alex Milowski wrote: I'm not sure this is exactly the right place to start, but I'll start here since the intersection of Andriod, iOS, and other developers are here. I've been testing some ideas for using the HTML5 canvas on mobile platforms versus desktop and I've notice an annoying feature on the mobile platforms. It is most noticeable on Android but also shows up on iOS on the iPad or iPod touch devices. The application involves the use of a HTML5 canvas that intercepts touch events on the canvas. Areas of a geometric image changes shading when touched to represent fractions of the object. On both platforms, there seems to be something about focus from the touch even that causes a highlight for the whole box containing the canvas element. On iOS, a gray shaded version of the canvas shows up for a very, very short period of time. It is inconsistent and depends how long the touch gesture is on the canvas. Some very short touch gestures do now cause the highlight of the canvas. That may be because it is just too short of a period of time to draw the highlight. On Andriod, any touch gesture cases a border and highlight around the canvas. Both are undesired effects. I'm trying to understand why the canvas has special highlight features for touch gestures over any other rendering object. Looking at the code, the highlight seems to be from the fact that RenderHTMLCanvas inherits from RenderReplaced just like RenderImage does. It all seems to key off of whether the canvas is selected. But the highlight isn't there for mouse clicks on desktop platforms. None of the CSS tricks (e.g. -webkit-user-select: none) seem to help on mobile platforms. It seems to me that on touch-enabled platforms (e.g. mobile) you should be able to disable this selection highlight behavior for canvas somehow. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection Highlight for Canvas Rendering Object on Mobile Platforms?
On Fri, Mar 11, 2011 at 3:35 PM, David Hyatt hy...@apple.com wrote: -webkit-tap-highlight-color: transparent is what you need I suspect (at least for iOS). Yes, that does fix it for iOS. Thanks! On Android, there is still some selection behavior but it is now slightly different and happens, oddly, every other tap. :( -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
