[webkit-dev] [Webkit GTK][Windows] Plug-ins fails to load

[dipak kumar]

Hi,

I have configured Webkit GTK port on Win32. Apart from that I have created
some NPAPI architecture based plug-in to implement my own functionality. I
have created DLL's and keeping them on the standard MOZ_PLUGIN_PATH path.
But my GTKLauncher application is unable to load these plug-ins. What I am
doing wrong? I couldn't find anything on net apart from a bug (
https://bugs.webkit.org/show_bug.cgi?id=54531 ). Could anybody please
confirm whether it is possible to load plug-in on windows or not.

Thanks,
Dipak
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Location of tests for new CSS features (regions and exclusions)

[Alan Stearns]

There are two patches in the works for regions and exclusions that include
tests:

https://bugs.webkit.org/show_bug.cgi?id=61726
https://bugs.webkit.org/show_bug.cgi?id=61730

The patches started with tests in these paths:

LayoutTests/fast/regions
LayoutTests/fast/exclusions

But during the responses to feedback, the test path schemes have diverged.
They are currently:

LayoutTests/fast/css-regions
LayoutTests/fast/css/exclusions

I am assuming that neither of these current paths are correct, since there
are no other examples using paths like them. But I do see CSS3 features in
different places - transitions tests have their own folder, but selector
tests are in a css3 folder.

So I'm guessing that either we should (1) use the original paths:

LayoutTests/fast/regions
LayoutTests/fast/exclusions

Or (2) move the folders into the css3 folder:

LayoutTests/fast/css3/regions
LayoutTests/fast/css3/exclusions

Unless I hear an argument for (2) I'm planning on submitting test patches
using (1).

Thanks,

Alan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Switching to new-run-webkit-tests

[Xan Lopez]

On Tue, Jun 28, 2011 at 1:17 AM, Eric Seidel  wrote:
> There appear to be 6 remaining blocking issues:
> https://bugs.webkit.org/showdependencytree.cgi?id=34984&hide_resolved=1
>
> We would like to hear from others who have tried new-run-webkit-tests,
> if they have issues which they believe should block migrating to NRWT.
>  (If so, please file and block the master bug!)

I can see the GTK+ port thing with Xvfb is there already, so not a lot
to add. NWRT is more sensitive to slow tests than the old
infrastructure, so we had to add a bunch of them to the expectations
file; I don't think this is particularly bad. In any case with the
Xvfb patch and my local expectations file things run beautifully and
way faster than before, so looking great from our side!

Xan

>
> Thanks.
>
> -eric
> ___
> 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

[webkit-dev] Switching to new-run-webkit-tests

[Eric Seidel]

Looking at the master bug, it looks like we're close to switching the
project to new-run-webkit-tests:
https://bugs.webkit.org/show_bug.cgi?id=34984

There appear to be 6 remaining blocking issues:
https://bugs.webkit.org/showdependencytree.cgi?id=34984&hide_resolved=1

We would like to hear from others who have tried new-run-webkit-tests,
if they have issues which they believe should block migrating to NRWT.
 (If so, please file and block the master bug!)

Thanks.

-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Ojan Vafai]

On Mon, Jun 27, 2011 at 3:17 PM, Alexey Proskuryakov  wrote:

> 27.06.2011, в 14:03, Darin Fisher написал(а):
> > I think we can make this behavior a Setting, and then certainly each
> embedder of WebKit
> > can decide how prominently to surface this option.  For Chrome, we'll
> probably either make
> > it be a command line flag, or we would just leave out the option
> entirely.
>
> Perhaps I'd be less unhappy about this change if the flag were off in
> layout tests, so that we didn't have to change them all to remove alert() in
> unload.


That patch was scrapped. Now alerts during unload handlers will just log to
the console, so the alerts can be left in. The expected results for the
tests will change a bit though since the message being logged is different.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Alexey Proskuryakov]

27.06.2011, в 14:03, Darin Fisher написал(а):

> I'm pretty surprised that you are so concerned about this change.  


I dislike magic APIs that work sometimes, but not always. In this case, the 
reason for crippling the API seems to be almost entirely about implementation 
issues - the discussion about whether it's good for improving user experience 
goes in rounds, possibly because anyone who wants to annoy users can just 
switch to beforeunload.

> I think we can make this behavior a Setting, and then certainly each embedder 
> of WebKit
> can decide how prominently to surface this option.  For Chrome, we'll 
> probably either make
> it be a command line flag, or we would just leave out the option entirely.


Perhaps I'd be less unhappy about this change if the flag were off in layout 
tests, so that we didn't have to change them all to remove alert() in unload.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposed Windows Drawing Change (WebNodeHighlight) Logic

[Brent Fulgham]

On Mon, Jun 27, 2011 at 5:36 AM, Adam Roben  wrote:
> On Jun 27, 2011, at 1:55 AM, Simon Fraser wrote:
>
>> This should go into a bug.
>
> Agreed.

Opened https://bugs.webkit.org/show_bug.cgi?id=63484.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Darin Fisher]

On Mon, Jun 27, 2011 at 1:40 PM, Alexey Proskuryakov  wrote:

>
> 26.06.2011, в 19:37, Sreeram Ramachandran написал(а):
>
> >> I'm not sure if historically browsers were often taking the liberty of
> crippling widely used features in this way. We didn't kill marquee, for
> instance. For another example, I know that a lot of users dislike animated
> GIFs, and yet we haven't removed support for those.
> >
> > Yet, we killed the blink tag and block popups. I don't think there's a
> > clear consistency here. Some things we deem to have crossed the line,
> > some we don't. In this case, Ian Hickson has suggested that blocking
> > alerts might be worth codifying into the standard
> > (https://bugs.webkit.org/show_bug.cgi?id=56397#c15).
>
> These examples are both somewhat different from blocking alerts as
> proposed:
> - Killing blink hardly removed any semantic meaning from pages.
> - Killing pop-ups did, so browsers have super accessible preferences and/or
> notifications for that. Note how Safari has the preference right in
> application menu.
>
> Perhaps the pop-up preference should be extended (and renamed) to cover the
> proposed behavior?
>
> - WBR, Alexey Proskuryakov
>
>

I don't understand the comparison you are making.  Popups are/were way more
common
than alerts generated from unload.  Way, way more common.

You mentioned marquee earlier.  That was only added by the Gecko engineers
because
their arms were twisted by management.  So sad.  There are plenty of other
IE'isms that
we did not implement, despite suffering web compat problems.

I'm pretty surprised that you are so concerned about this change.  It seems
like we have
learned that alerts in unload handlers are not very common.  Yes, they are
more common
than expected, but upon closer inspection the usage is poor (trying
to prevent users from
leaving a site).

For multi-process browsers, we see a big benefit to be had by disallowing
these dialogs.
It would potentially allow us to hide tabs immediately when the user closes
them.  We
would no longer need to keep the tab visible while we wait for the unload
handler to run.
Keep in mind that in a multi-process browser, the tab being closed could be
bound to a
process that is entirely swapped out.  Paging it in to run unload handlers
could be very
costly.  Alternative solutions, like bringing the hidden tab back into view
when it pops up
an alert, are not satisfactory either.  That leads to ripping the user's
focus away from what
they want to do next.  That's not good UI.

I think we can make this behavior a Setting, and then certainly each
embedder of WebKit
can decide how prominently to surface this option.  For Chrome, we'll
probably either make
it be a command line flag, or we would just leave out the option entirely.

Regards,
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Adam Barth]

On Mon, Jun 27, 2011 at 1:40 PM, Alexey Proskuryakov  wrote:
>
> 26.06.2011, в 19:37, Sreeram Ramachandran написал(а):
>
>>> I'm not sure if historically browsers were often taking the liberty of 
>>> crippling widely used features in this way. We didn't kill marquee, for 
>>> instance. For another example, I know that a lot of users dislike animated 
>>> GIFs, and yet we haven't removed support for those.
>>
>> Yet, we killed the blink tag and block popups. I don't think there's a
>> clear consistency here. Some things we deem to have crossed the line,
>> some we don't. In this case, Ian Hickson has suggested that blocking
>> alerts might be worth codifying into the standard
>> (https://bugs.webkit.org/show_bug.cgi?id=56397#c15).
>
> These examples are both somewhat different from blocking alerts as proposed:
> - Killing blink hardly removed any semantic meaning from pages.
> - Killing pop-ups did, so browsers have super accessible preferences and/or 
> notifications for that. Note how Safari has the preference right in 
> application menu.
>
> Perhaps the pop-up preference should be extended (and renamed) to cover the 
> proposed behavior?

That sounds like an application-level decision.

In any case, I agree with Darin that the next step here is to try it
in a dev channel release.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Alexey Proskuryakov]

26.06.2011, в 19:37, Sreeram Ramachandran написал(а):

>> I'm not sure if historically browsers were often taking the liberty of 
>> crippling widely used features in this way. We didn't kill marquee, for 
>> instance. For another example, I know that a lot of users dislike animated 
>> GIFs, and yet we haven't removed support for those.
> 
> Yet, we killed the blink tag and block popups. I don't think there's a
> clear consistency here. Some things we deem to have crossed the line,
> some we don't. In this case, Ian Hickson has suggested that blocking
> alerts might be worth codifying into the standard
> (https://bugs.webkit.org/show_bug.cgi?id=56397#c15).

These examples are both somewhat different from blocking alerts as proposed:
- Killing blink hardly removed any semantic meaning from pages.
- Killing pop-ups did, so browsers have super accessible preferences and/or 
notifications for that. Note how Safari has the preference right in application 
menu.

Perhaps the pop-up preference should be extended (and renamed) to cover the 
proposed behavior?

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore

[Ojan Vafai]

Can you give an example of a smooth UI that you'd need the more complex API
for? When I think of the existing mail and chat apps in iOS/Android that
I've use,  could give just as smooth a UI as the
existing apps, it's just on the browser side to make the UI good instead of
on the web developer side.

Ojan

On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou  wrote:

> A user agent defined solution will make apps like mail, chat,
> Facebook, and so on all feel awful in safari versus installing a
> native app. It's like j2me all over again unless the website can
> provide a smooth ui.
>
> Alex
>
> On Friday, June 24, 2011, Ojan Vafai  wrote:
> > Is there a document that lists the use-cases for this API? I couldn't
> find anything from a quick glance through the DAP working group's mailing
> list archive. A list of use-cases would help evaluate whether this is the
> best API. At first glance, it strikes me that something like  type=contacts> would meet the uses-cases I can think of better.
> >
> >
> > Ojan
> >
> > On Thu, Jun 23, 2011 at 11:28 PM, 김동관  wrote:
> >
> >
> > Hi webkit-dev!
> >
> > I wanted to let you know that I plan to add Contacts API support to
> WebKit.
> > This API is a new feature that is published by W3C.
> > The Device APIs Working Group of W3C has just released a Last Call
> Working Draft of its Contacts API:
> > http://www.w3.org/TR/2011/WD-contacts-api-20110616/
> >
> > I'm going to commit patch for Contacts API implementation very soon.
> >
> > This support will be behind the ENABLE_CONTACTS feature define. See:
> > https://bugs.webkit.org/show_bug.cgi?id=63223
> >
> > We'll be setting up a buildbot to track then ENABLE_CONTACTS build
> shortly. We expect
> > this feature to be eventually enabled by all ports.
> > Looking forward to your comments.
> >
> > Thank you.
> >
> > Donggwan
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> >
>
> --
> --
> Try Gmail Offline for Chrome  >,
> and send me your complaints!
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Sreeram Ramachandran]

On Mon, Jun 27, 2011 at 00:11, Ryosuke Niwa  wrote:
> On Sun, Jun 26, 2011 at 11:48 PM, Sreeram Ramachandran
>  wrote:
>>
>> I think the performance benefit and reduction in code complexity are
>> secondary. Reducing user annoyance is the number one priority.
>
> But websites can annoy users by many other means.  It seems like all we need
> is a "do not show again" checkbox rather than disallowing
> them indiscriminately.

Yes, websites can annoy users in many ways. Shouldn't we disable those
techniques we consider egregious, especially if they add little value
to the user or are universally disliked (cf: examples cited so far:
blink, popups)? In addition, users need the browser's help
particularly when they are trying to quit an annoying page, and the
page just won't let go. We already have the "do not show again"
checkbox. But clearly (from the stats in the original mail), there's
potential to do more.

As I said before, I haven't seen a case of anybody using a
confirm/prompt for a reasonable purpose in beforeunload. Here's an
example of the contrary, a site that pops up an alert in beforeunload:
http://www.80move.cn/

>> I'd prefer to keep things consistent and just disallow all modal dialogs
>> in all types of unload handlers (beforeunload, pagehide and unload).
>
> Why is that good or necessary?
> beforeunload and unload have very different semantics.  beforeunload is
> fired before a page is unloaded to make the navigation cancelable and
> prepare for unloading the page whereas unload is fired AFTER the page
> dismissal has started.  At this point, the navigation cannot be stopped and
> all script can do is to save states, etc...
> Given these semantics, it seems okay to disallow modal dialogs in unload
> event because the navigation cannot be canceled after unload event is fired
> and, in fact, browser has already started unloading the page. On the other
> hand, disallowing modal dialogs in beforeunload event seems weird to me
> because the navigation can still be canceled and the browser hasn't (and
> shouldn't have) started evicting the page.

I think the difference in semantics between beforeunload and unload is
perfectly captured by the return value. I don't see why other modal
dialogs enter into it. In fact, we've long recognized that people can
abuse beforeunload/unload in various ways and we've taken steps to
mitigate them:

1. Developers have tried to abuse the return string from beforeunload
to confuse users and click on the wrong button. So much so that
Firefox has ended up not showing the return string altogether, which I
think moves the needle too far in the other direction (see the long
list of comments at
https://bugzilla.mozilla.org/show_bug.cgi?id=588292). I think our
compromise of showing the return string, but making the buttons
unambiguous ("Stay/Leave" instead of "OK/Cancel" or "Yes/No") is the
right balance.

2. Developers have tried to put long delays in unload and sleeping
forever (and indeed, avoiding the script-hang-monitor timeout). We've
hacked around them (http://webkit.org/b/29193, http://crbug.com/7823,
https://lists.webkit.org/pipermail/webkit-dev/2009-September/009925.html).

3. Developers try to load resources, navigate to other pages, etc. We
rightly block such attempts from unload. However, there's a legitimate
need to send pings for analytics, so we compromise by allowing image
requests to outlive the page (http://webkit.org/b/30457).

To summarize, each of the above can be considered a legitimate
developer need, but we find that more often than not, they are abused.
In many cases, we have been able to support the legitimate use case by
offering a compromise. I consider disallowing modal dialogs but
allowing the return value to popup the stay-or-leave dialog to be a
similarly good compromise between the needs of developers and users.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposed Windows Drawing Change (WebNodeHighlight) Logic

[Adam Roben]

On Jun 27, 2011, at 1:55 AM, Simon Fraser wrote:

> This should go into a bug.

Agreed.

> On Jun 26, 2011, at 4:12 PM, Brent Fulgham wrote:
> 
>> While investigating a separate issue, I noticed that I was hitting an 
>> assertion in the Cairo drawing layer because it was attempting to use an 
>> invalid HBITMAP created in the WebNodeHighlight::update method.  The 
>> underlying issue was that the CreateDIBSection function was failing, because 
>> it was being requested to create a section of zero height.
>> 
>> I think the following change would be safe for the CoreGraphics and Cairo 
>> ports, but wanted to see if anyone knew of a reason why it would be bad to 
>> exit early in the case of a zero height (or zero width) paint region.
>> 
>> $ svn diff
>> Index: win/WebNodeHighlight.cpp
>> ===
>> --- win/WebNodeHighlight.cpp(revision 89759)
>> +++ win/WebNodeHighlight.cpp(working copy)
>> @@ -145,10 +145,14 @@
>>size.cx = webViewRect.right - webViewRect.left;
>>size.cy = webViewRect.bottom - webViewRect.top;
>> 
>> +if (!size.cx || !size.cy)
>> +return;
>> +
>>BitmapInfo bitmapInfo = BitmapInfo::createBottomUp(IntSize(size));
>> 
>>void* pixels = 0;
>>OwnPtr hbmp = adoptPtr(::CreateDIBSection(hdc, &bitmapInfo, 
>> DIB_RG
>> B_COLORS, &pixels, 0, 0));
>> +ASSERT_WITH_MESSAGE(hbmp.get(), "::CreateDIBSection failed with error 
>> %lu",
>> ::GetLastError());
>> 
>>::SelectObject(hdc, hbmp.get());

I don't see any reason why this would be bad.

-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore

[Alex Russell]

On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai  wrote:

> Is there a document that lists the use-cases for this API? I couldn't find
> anything from a quick glance through the DAP working group's mailing list
> archive. A list of use-cases would help evaluate whether this is the best
> API. At first glance, it strikes me that something like  type=contacts> would meet the uses-cases I can think of better.


Seconded.


> On Thu, Jun 23, 2011 at 11:28 PM, 김동관  wrote:
>
>> Hi webkit-dev!
>>
>> I wanted to let you know that I plan to add Contacts API support to
>> WebKit.
>> This API is a new feature that is published by W3C.
>> The Device APIs Working Group of W3C has just released a Last Call Working
>> Draft of its Contacts API:
>>http://www.w3.org/TR/2011/WD-contacts-api-20110616/
>>
>> I'm going to commit patch for Contacts API implementation very soon.
>>
>> This support will be behind the ENABLE_CONTACTS feature define. See:
>> https://bugs.webkit.org/show_bug.cgi?id=63223
>>
>> We'll be setting up a buildbot to track then ENABLE_CONTACTS build
>> shortly. We expect
>> this feature to be eventually enabled by all ports.
>> Looking forward to your comments.
>>
>> Thank you.
>>
>> Donggwan
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] The case for disallowing alerts in unload, redux

[Ryosuke Niwa]

On Sun, Jun 26, 2011 at 11:48 PM, Sreeram Ramachandran  wrote:
>
> I think the performance benefit and reduction in code complexity are
> secondary. Reducing user annoyance is the number one priority.
>

But websites can annoy users by many other means.  It seems like all we need
is a "do not show again" checkbox rather than disallowing
them indiscriminately.


> I'd prefer to keep things consistent and just disallow all modal dialogs
> in all types of unload handlers (beforeunload, pagehide and unload).
>

Why is that good or necessary?

beforeunload and unload have very different semantics.  beforeunload is
fired before a page is unloaded to make the navigation cancelable and
prepare for unloading the page whereas unload is fired AFTER the page
dismissal has started.  At this point, the navigation cannot be stopped and
all script can do is to save states, etc...

Given these semantics, it seems okay to disallow modal dialogs in unload
event because the navigation cannot be canceled after unload event is fired
and, in fact, browser has already started unloading the page. On the other
hand, disallowing modal dialogs in beforeunload event seems weird to me
because the navigation can still be canceled and the browser hasn't (and
shouldn't have) started evicting the page.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev