Re: [webkit-dev] [chromium] as of r131699, the chromium port no longer uses any baselines from LayoutTests/platform/mac

2012-10-18 Thread Dirk Pranke
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

2012-10-18 Thread Pierre-Antoine LaFayette
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

2012-10-18 Thread Simon Fraser
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

2012-10-18 Thread Pierre-Antoine LaFayette
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

2012-10-18 Thread Wez
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

2012-10-18 Thread Brian Weinstein
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