I have find way to do it,my code
bool QWebPage::canInput(QRect pos)
{
bool ret=false;
#if 0
Frame *frame = d-page-focusController()-focusedFrame();
qDebug()ryan can input1:(frame?1:0);
#endif WebCore::Frame *frame1 =
d-page-focusController()-focusedOrMainFrame();
Node *
On Tue, Nov 24, 2009 at 11:21 PM, Maciej Stachowiak m...@apple.com wrote:
If we tie it to an element or attribute, people may be tempted to just do it
in markup, which would be insecure.
Maybe we should have a DOM API called
webkitJailChildren(no-script-for-you) on Node that prevents future
Why are some layout tests renamed with a suffix of -disabled? Why aren't
such tests simply added to the skipped list? Is -disabled simply the old
way?
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote:
Why are some layout tests renamed with a suffix of -disabled? Why aren't
such tests simply added to the skipped list? Is -disabled simply the old way?
Usually a test is disabled, with a bug filed to re-enable it, when a WebKit bug
makes it
On Wed, Nov 25, 2009 at 10:44 AM, Dan Bernstein m...@apple.com wrote:
On Nov 25, 2009, at 10:38 AM, Darin Fisher wrote:
On Wed, Nov 25, 2009 at 10:35 AM, Dan Bernstein m...@apple.com wrote:
On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote:
Why are some layout tests renamed with a suffix
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020191.html
I think we should experiment with the minimal API that seems useful.
If the experiment is a success, we can scale it up.
Apologies if I am rehashing something discussed earlier, but I think it
would be easy to run into
I'd rather not go this route in our initial implementation. I think
we should target the use case of a web site receiving an untrusted
string via cross-origin XMLHttpRequest or postMessage.
Fair enough. OTOH, this solves a very narrow problem. If we have an
implementation that at least
Hi,
I have a doubt regarding the content of webkit render tree dump. In this
dump, do we only print the HTML node information(body, div etc) or we print
the style information also(font-weight, text-decoration etc). From what I
have seen, it looks like only node information is printed. In such a
Hello,
I am writing my own class using ImageLoader. Can somebody, please, help me
with these questions:
1. How do I know that the image was loaded already? Can I set up callback
somehow?
2. What should functions sourceURI() and dispatchLoadEvent() do?
3. What is pixel format
for
On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
On Tue, Nov 24, 2009 at 11:21 PM, Maciej Stachowiak m...@apple.com
wrote:
If we tie it to an element or attribute, people may be tempted to
just do it
in markup, which would be insecure.
Maybe we should have a DOM API called
On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak m...@apple.com
wrote:
On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
Maybe we should have a DOM API called
webkitJailChildren(no-script-for-you) on Node that prevents future
children from
On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
Maybe we should have a DOM API called
The other way to skin this cat, by the way, is to implement the
seamless attribute on iframes. That gives you a similar sort of
design using the @sandbox attribute and solves many of your above
concerns, e.g. by creating a new namespace for @ids. Maybe we should
try that first or in
On Nov 25, 2009, at 1:33 PM, Adam Barth wrote:
On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak m...@apple.com
wrote:
On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak
m...@apple.com wrote:
On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
On Nov 25, 2009, at 1:45 PM, Michal Zalewski wrote:
The other way to skin this cat, by the way, is to implement the
seamless attribute on iframes. That gives you a similar sort of
design using the @sandbox attribute and solves many of your above
concerns, e.g. by creating a new namespace for
Hi Dmitry,
As I have noted to others on the Chrome team, I do not think this is good
idea and I don't think we should have it in WebKit. It adds extra
complexity to WebKit and gives little beyond what is possible using
inter-window communication and SharedWorkers. I think we need to give more
Hi Sam!
Thanks a lot for sharing your perspective! I really wish your reply
had, in addition to the statement of the opinion, an argument or just
more explanation of why you think so. I think we covered SharedWorkers
and inter-window communication in the previous discussions and in the
design
On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov dim...@chromium.org wrote:
BTW, could you tell what's the 'course' that would be reverted?
Meaning, before we decide that SharedWorkers and inter-window communication
are insufficient, and a further proposal should be entertained by the
standards
On Wed, Nov 25, 2009 at 1:49 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 25, 2009, at 1:33 PM, Adam Barth wrote:
I don't have a complete design in mind. I could try to write up a
design document.
Sounds like we could use one given the potential complications.
I've sketched out a
19 matches
Mail list logo
