Re: [webkit-dev] [chromium] as of r131699, the chromium port no longer uses any baselines from LayoutTests/platform/mac
It's not a tree, it's still a DAG, because of the wk2 baselines as Adam says. Note that my change didn't really change the shape of the tree (previously all the chromium ports fell back to platform/chromium then platform/mac, then the generic results. I just removed a node). -- Dirk On Wed, Oct 17, 2012 at 10:11 PM, Adam Barth aba...@webkit.org wrote: We should update the graph. It might be a tree now. The only complication might be the wk2 baselines. Adam On Wed, Oct 17, 2012 at 9:53 PM, Eric Seidel e...@webkit.org wrote: Does that mean our fallback graph is now finally a tree?? :) https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit On Wed, Oct 17, 2012 at 8:15 PM, Dirk Pranke dpra...@chromium.org wrote: All of the Chromium ports will use baselines in their port-specific directories, then fall back through various paths to platform/chromium and then to next to the test. Which means you Apple folks can feel free to break things in platform/mac to your hearts' content :). Let me know if you see any weirdness or problems. Thanks! -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Canvas Layout Behaviour after Device Orientation Change
I'm looking at a layout issue on mobile and would like someone to help clarify what behaviour would be expected. Below I will describe this issue: The web page is composed of a 1024x1024 canvas with style=width:100%; height: 100%, does not specify viewport meta tag, rather just uses the platform default (980 in my case). Device loads the page in landscape mode, the canvas takes up the entire viewport, and is zoomed out completely (can see the full canvas). Rotate the device to portrait mode What would be the expected layout? Should the canvas be zoomed out to fit the width of the device in portrait mode? Should the canvas width be preserved and the canvas be clipped at the device width boundary allowing to scroll to see the rest of the canvas? Rotate the device to landscape mode I imagine the layout should now be the same as when loaded initially. Any thoughts or opinions on what the correct layout behaviour should be here would be much appreciated. I'm not sure if there is a formal specification for this or if it left as an exercise for the vendor. Thanks, Pierre ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Canvas Layout Behaviour after Device Orientation Change
The behavior should be exactly the same as it would be for img style=width:100%; height: 100%. The fact that it's a canvas should not affect layout behavior. Simon On Oct 18, 2012, at 12:21 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: I'm looking at a layout issue on mobile and would like someone to help clarify what behaviour would be expected. Below I will describe this issue: The web page is composed of a 1024x1024 canvas with style=width:100%; height: 100%, does not specify viewport meta tag, rather just uses the platform default (980 in my case). Device loads the page in landscape mode, the canvas takes up the entire viewport, and is zoomed out completely (can see the full canvas). Rotate the device to portrait mode What would be the expected layout? Should the canvas be zoomed out to fit the width of the device in portrait mode? Should the canvas width be preserved and the canvas be clipped at the device width boundary allowing to scroll to see the rest of the canvas? Rotate the device to landscape mode I imagine the layout should now be the same as when loaded initially. Any thoughts or opinions on what the correct layout behaviour should be here would be much appreciated. I'm not sure if there is a formal specification for this or if it left as an exercise for the vendor. Thanks, Pierre ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Canvas Layout Behaviour after Device Orientation Change
Ok great! That'll help with debugging. What would be the expected layout of the img of that size after an orientation change? Or if there is a specification of this somewhere could you point me in the right direction? Thanks, Pierre On 18 October 2012 16:23, Simon Fraser simon.fra...@apple.com wrote: The behavior should be exactly the same as it would be for img style=width:100%; height: 100%. The fact that it's a canvas should not affect layout behavior. Simon On Oct 18, 2012, at 12:21 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: I'm looking at a layout issue on mobile and would like someone to help clarify what behaviour would be expected. Below I will describe this issue: The web page is composed of a 1024x1024 canvas with style=width:100%; height: 100%, does not specify viewport meta tag, rather just uses the platform default (980 in my case). Device loads the page in landscape mode, the canvas takes up the entire viewport, and is zoomed out completely (can see the full canvas). Rotate the device to portrait mode What would be the expected layout? Should the canvas be zoomed out to fit the width of the device in portrait mode? Should the canvas width be preserved and the canvas be clipped at the device width boundary allowing to scroll to see the rest of the canvas? Rotate the device to landscape mode I imagine the layout should now be the same as when loaded initially. Any thoughts or opinions on what the correct layout behaviour should be here would be much appreciated. I'm not sure if there is a formal specification for this or if it left as an exercise for the vendor. Thanks, Pierre ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit DOM 3 Events
Hello WebKitters, The DOM 3 Events spec seems to have reached a reasonably stable state. Is there interest in updating WebKit to match the spec, e.g. in areas like keyboard input, where WebKit currently implements an older draft? Thanks, Wez @ Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Touch operation corrupts screen when specifying other than overflow:visible in css
Please file a bug at https://bugs.webkit.org with the component WebKit Misc. and attach your test case as an HTML file. Please also CC me on it (bweinst...@apple.com). Thanks! Brian Weinstein On Oct 17, 2012, at 12:58 AM, HIDEKI YOSHIDA yoshida-...@necst.nec.co.jp wrote: Hi, On a windows 7 tablet, PAN operation(=scroll) causes corruption of screen. Does anybody know how to resolve this or have the fix? How to reproduce. 1. Prepare a HTML contents which have an element specifying other than visible to the property overflow in css. 2. Load the contents with webkit 3. Operate the touch operaion, PAN on the element. Problem The content in the element protrudes outside the placeholder for it and can disappear. The build version Webkit.exe on r131112 for Nightly builds We guess Source\WebKit\win\WebView.cpp has some bugs on this issue. Here is the sample contents to reproduce problem. You will see the problem if you PAN on the field for overflow:auto. -- HTML HEADTITLEpan with css:overflow/TITLE/HEAD BODY font size=+2 div style=border: 2px solid blue; padding: 5px 5px 5px 5px; overflow:visible; overflow:visible /div br div style=border: 2px solid red; padding: 5px 5px 5px 5px; overflow:auto; overflow:auto /div /font /BODY /HTML -- Hideki *** Hideki Yoshida Embedded Software Division NEC System Technologies, Ltd. E-MAIL:yoshida-...@necst.nec.co.jp *** ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev