[webkit-dev] Alt text not shown when AutoLoadImages is turned off

I've noticed that when AutoLoadImages is turned off, the area where an image would be is totally blank. I'd expect to see the alt or title text, and maybe a border. George Staikos tells me that WebKit's always done this, but he can't remember the rationale. Is this by design? If so, what's the r

Re: [webkit-dev] Style question: static, protected, or public members

I'm strongly in favour of g_. It seems weird and ugly to me to have prefixes for some non-local scopes but not all. And it's very helpful to be able to look at a variable reference and immediately know that it's a global, and not a local whose definition you skimmed over. Joe -Original Mess

Re: [webkit-dev] Stability problems involving Javascript GC

> -Original Message- > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- > boun...@lists.webkit.org] On Behalf Of Samuel Rivas > Sent: Thursday, December 16, 2010 3:03 AM > To: Zoltan Herczeg > Cc: webkit-dev Development > Subject: Re: [webkit-dev] Stability problems involving J

[webkit-dev] Getting at Settings object from WorkerContext

I'm trying to add a setting to enable/disable WebSockets at runtime (so that the browser can make websockets available as a user preference, for instance). It's easy to add a flag to Settings, and check it from JSDOMWindowCustom::webSocket to return undefined for the websocket object when it's

Re: [webkit-dev] Getting at Settings object from WorkerContext

Aha, there is already a "websocketsEnabled" method there! Thanks, that's perfect. From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Thursday, January 06, 2011 1:25 PM To: Joe Mason Cc: webkit-dev Development Subject: Re: [webkit-dev] Getting at

Re: [webkit-dev] Getting at Settings object from WorkerContext

eGeneratorV8.pm, but not any other code generator. Is this a V8-only thing? Joe From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Joe Mason Sent: Thursday, January 06, 2011 1:52 PM To: Jeremy Orlow Cc: webkit-dev Development Subject: Re: [webkit-

[webkit-dev] RuntimeEnabledFeatures for JSC (was RE: Getting at Settings object from WorkerContext)

Sent: Thursday, January 06, 2011 2:43 PM To: Joe Mason Cc: webkit-dev Development Subject: Re: [webkit-dev] Getting at Settings object from WorkerContext Btw, the reason that this behavior has to live in the bindings and not WebCore is to ensure feature detection code still works. For example,

Re: [webkit-dev] RuntimeEnabledFeatures for JSC (was RE: Getting at Settings object from WorkerContext)

> -Original Message- > From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam > Barth > > That's one my list of things I'd like to do, but my Perl isn't strong > enough yet. :( I'm pretty sure my Perl is worse than yours, unfortunately. Perl and I do not get along. I've fi

Re: [webkit-dev] RuntimeEnabledFeatures for JSC (was RE: Getting at Settings object from WorkerContext)

> From: da...@google.com [mailto:da...@google.com] On Behalf Of Darin Fisher > > IIRC, there was not much interest from JSC-using ports > for RuntimeEnabledFeatures. Well, there is now! Joe - This transmission (including any at

[webkit-dev] Scope of FrameLoader::isProcessingUserGesture

In our platform implementation of dispatchWillPerformClientRedirect, we check whether the redirect was triggered by a user gesture: m_frame->loader()->isProcessingUserGesture() Since svn rev 65082, isProcessingUserGesture returns true when processing a meta tag refresh. We have a fix for this,

Re: [webkit-dev] Scope of FrameLoader::isProcessingUserGesture

Since nobody answered in the negative I filed this as https://bugs.webkit.org/show_bug.cgi?id=52211 > -Original Message- > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- > boun...@lists.webkit.org] On Behalf Of Joe Mason > Sent: Monday, January 10, 2011

Re: [webkit-dev] How to add a new file to mac build system?

WebCore/bindings/scripts/CodeGenerator*.pm From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Won J Jeon Sent: Tuesday, January 25, 2011 4:13 PM To: Mihai Parparita Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] How to add a new file to

Re: [webkit-dev] about QtWebKit documentation

I'm not clear from your question what you're trying to do. If you're just trying to write an app using the Qt port of WebKit, you should ask on webkit-h...@lists.webkit.org. This list is only for developing WebKit itself. The interface layer between Qt and

Re: [webkit-dev] when will pages group into different PageGroup

An example of when you would use page groups is if you write an app which includes an embedded browser (for displaying help pages, perhaps) but also draws some of its own interface using HTML/CSS, you would want different settings to apply to the browser pages and to the app's interface itself.

Re: [webkit-dev] Dropping support for WML?

Blackberry needs to continue to support WML, but we are using our own (legacy) code as a plugin, so removing it from webkit is mostly fine with us. We just use two pieces of the WML code, to deal with the different loading model required by WML: In FrameLoader::shouldReload: // All WML de

Re: [webkit-dev] Removing Support for Python 2.5

Has there been any thought of moving to "/usr/bin/env python" for systems with python installed in a different path? > -Original Message- > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- > boun...@lists.webkit.org] On Behalf Of Adam Barth > Sent: Monday, November 07, 2011 4

Re: [webkit-dev] Removing support for the RVCT compiler

Yes, Blackberry uses RVCT (4.1 currently, so I believe 2.2 workarounds can be removed from our point of view.) > -Original Message- > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- > boun...@lists.webkit.org] On Behalf Of Simon Hausmann > Sent: Monday, December 12, 2011 6:4

Re: [webkit-dev] URL validating process in WebKit

If you are using webkit to author a browser, rather than making changes to webkit itself, you should ask questions on webkit-h...@lists.webkit.org. Assuming you're writing code in a layer that has access to KURL, just pass your string to KURL and call isValid(). > -Original Message- > F

Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore

The BlackBerry port uses BlackBerry::Platform for its system libraries - it wouldn't surprise me if some of our files in the platform dirs have "using BlackBerry" so they can just use "Platform::symbol" instead of "BlackBerry::Platform::symbol" in the source. Shouldn't be hard to sort out, tho

Re: [webkit-dev] How to use ASSERT_NO_EXCEPTION

> -Original Message- > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- > boun...@lists.webkit.org] On Behalf Of Darin Adler > Sent: Thursday, December 15, 2011 11:37 AM > To: WebKit Development > Subject: [webkit-dev] How to use ASSERT_NO_EXCEPTION > > Those same functions ar

Re: [webkit-dev] Top 100 sites browsing tests proprosal

I don't think this needs to be done by every developer on every checkin. It could be done by the buildbots daily, and whenever a crash is found, somebody would need to find the cause and turn it into a real regression test for later. The fact that the web sites change over time isn't important

Re: [webkit-dev] Top 100 sites browsing tests proprosal

People run test builds against live servers by hand all the time. As long as we don't do it too often, I don't see a problem. Especially as this list would be taken from a list of "top 100" web sites, which presumably would each be big enough to handle the traffic. > -Original Message

Re: [webkit-dev] Changing the implementation of KURL

> -Original Message- > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- > boun...@lists.webkit.org] On Behalf Of Adam Barth > Sent: Saturday, January 28, 2012 3:20 AM > To: Darin Fisher > Cc: Benjamin Poulain; WebKit Development > Subject: Re: [webkit-dev] Changing the implemen

Re: [webkit-dev] Changing the implementation of KURL

> -Original Message- > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- > boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak > Sent: Saturday, January 28, 2012 7:08 PM > To: Brett Wilson > Cc: Benjamin Poulain; WebKit Development > Subject: Re: [webkit-dev] Changing the i

Re: [webkit-dev] Adding to WebCore

What happens if this extra plumbing isn't one? Is the tag just ignored? From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Jochen Eisinger [joc...@chromium.org] Sent: Tuesday, March 06, 2012 10:58 AM To: WebKit Deve

Re: [webkit-dev] Adding to WebCore

Yes, thank you. From: eisin...@google.com [eisin...@google.com] on behalf of Jochen Eisinger [joc...@chromium.org] Sent: Tuesday, March 06, 2012 11:38 AM To: Joe Mason Cc: WebKit Development Subject: Re: [webkit-dev] Adding to WebCore On Tue, Mar 6, 2012

Re: [webkit-dev] Moving to Git?

It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn withou

Re: [webkit-dev] Moving to Git?

g it. As for the > > difficulty of resolving conflicts between patches you've made locally and > > changes made on the shared repository since you started making your local > > patches... nothing about git makes this any harder. Unless you have a > > lock based source

Re: [webkit-dev] Moving to Git?

dy "commit 8" only works if they're starting from the same point. Which makes them not incredibly useful. From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 4:25

Re: [webkit-dev] Moving to Git?

llow up on my old post since my message was cut off in the middle: On Thu, Mar 8, 2012 at 1:25 PM, Ryosuke Niwa mailto:rn...@webkit.org>> wrote: On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason mailto:jma...@rim.com>> wrote: This is only slightly more complicated I'd say astoundingly more co

Re: [webkit-dev] Dropping support of old WebSocket protocol

Totally on board with this. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Friday, March 16, 2012 2:06 PM To: Yuta Kitamura Cc: WebKit Development Subject: Re: [webkit-dev] Dropping

[webkit-dev] Pointers and self-documenting code

As has been noted in a recent thread, WebKit strives to make the code clear and understandable rather than have embedded comments that can become obsolete. One common practice that I find quite opaque is for classes to have functions returning pointers which can never return 0, especially when

Re: [webkit-dev] Pointers and self-documenting code

> From: Filip Pizlo [fpi...@apple.com] > Sent: Friday, July 06, 2012 4:52 PM > To: Joe Mason > Cc: WebKit Development ‎[webkit-dev@lists.webkit.org]‎ > Subject: Re: [webkit-dev] Pointers and self-documenting code > > It's not at all clear that this is correct. > >

Re: [webkit-dev] Do we need a "webkitBackground" property for XMLHttpRequest?

> From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Adam Barth > [aba...@webkit.org] > > > Do you know why the chromium has not cancel auth dialog for XHR? Is this > > the main reason? > > The network stack folks did a round of removing auth dialogs

Re: [webkit-dev] Do we need a "webkitBackground" property for XMLHttpRequest?

> From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Adam Barth > [aba...@webkit.org] > > The network stack folks did a round of removing auth dialogs for > subresources a while back. I'm not sure why they didn't remove the > dialog from XHR. It's po

Re: [webkit-dev] Do we need a "webkitBackground" property for XMLHttpRequest?

> From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Brady Eidson > [beid...@apple.com] > > I think there are corporate/financial apps that would break if this was > policy. Any idea which? Joe ---

Re: [webkit-dev] Do we need a "webkitBackground" property for XMLHttpRequest?

> From: aba...@gmail.com [aba...@gmail.com] on behalf of Adam Barth > [aba...@webkit.org] > > There is no such thing as "pushing to trunk" for Chromium. All > development happens on trunk. That sounds like a regression. I'll > follow up with the networking folks. Thanks! Mind keeping us up t

Re: [webkit-dev] Not authorized to access Bugzillia

Security bugs are restricted so that security holes aren't made public until they're fixed. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of talking1...@gmail.com [talking1...@gmail.com] Sent: Wednesday, August 08, 2012

Re: [webkit-dev] Proposal for coding guidelines: Do not use fall-through switch cases inside #ifdef's

> From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Bruno Abinader > [brunoabina...@gmail.com] > Sent: Friday, August 17, 2012 12:32 PM > To: WebKit Development > Subject: [webkit-dev] Proposal for coding guidelines: Do not use fall-through > switch c

Re: [webkit-dev] Proposal: WTF HashMap iterators to use key/value instead first/second

I'm in favour of this change, as WTF::HashMap is not std::map and having the interface be almost like std::map in some ways, but totally unlike it in other ways, is more confusing than a clean break would be. From: webkit-dev-boun...@lists.webkit.org [webk

Re: [webkit-dev] to reitveld or not to reitveld

Mark Rowe wrote: - UI is intimidating to newcomers. This is clearly subjective, but since the goal here is to make the review process friendlier, especially for new contributors, I think it deserves calling out. FWIW, after playing around with it for a few minutes I find its UI much, much frie

Re: [webkit-dev] to reitveld or not to reitveld

Joe Mason wrote: Agreed. I expect will all end up calling it rfield soon enough (and I even typed that as rfiled the first time). I mean rveld, of course. I've been rereading Dracula, I think it's affecting my brain... Joe ___ webkit-d

Re: [webkit-dev] to reitveld or not to reitveld

Mark Rowe wrote: On 2009-06-11, at 15:16, Ojan Vafai wrote: On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai > wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mailto:mr...@apple.com>> wrote: There are also concerns about access to the data store of the

Re: [webkit-dev] Puzzled, can anyone give me a hint?

TianShijun wrote: > Hi All, > I am reviewing the code of WebKit. I found that in PluginView.h/cpp , > only one method (setPlatformPluginWidget) can set the private member > PluginView::m_window to be non-zero. > > I have searched all the codes and found that only PluginViewMac.cpp > has invoked thi

Re: [webkit-dev] Puzzled, can anyone give me a hint?

TianShijun wrote: > Hi Joe, > Now I get to know how it work in Qt/Windows. But i found that in > Qt/X11, only PluginView.cpp and PluginViewQt.cpp will be compiled. Is > that mean all the platformPluginWidget() will return 0? There are many > "platformPluginWidget()->foo()" in PluginViewQt.cpp. Tak

Re: [webkit-dev] opera unite api: extensions to add web server capability to browser engines

Luke Kenneth Casson Leighton wrote: perhaps a better question is, instead of saying "it's not possible, it's not possible", is to ask: how can the javascript namespace be extended? This might indeed be a better question, and it's a shame you didn't ask it in the first place. how can object

Re: [webkit-dev] Review states

Eric Seidel wrote: I propose altering our bugzilla setup to have the following review states (effectively adding a 4th state): review: REQUESTED DENIED APPROVED WITH MODIFICATIONS APPROVED Sounds good. The name "Approved with modifications" is a little verbose, though. Also, when making th

Re: [webkit-dev] Review states

Eric Seidel wrote: It would appear bugzilla is too lame to support changing flag values +/-/? are all we get. :( https://bugs.webkit.org/editflagtypes.cgi (only accessible to bugzilla users with edit privilages). Maybe the solution is a different review tool instead of adding flags to attachment

Re: [webkit-dev] Changes to prepare-ChangeLog

Maciej Stachowiak wrote: With SVN at least, it's a lot faster and easier to do a text search on the ChangeLog than to retrieve and search the commit log history. Searching the actual commit logs is very slow online and doesn't work at all offline. The ChangeLog also ends up in static tarball

Re: [webkit-dev] ChangeLog

Darin Adler wrote: My experience on other projects that don’t use ChangeLog is that many check-ins don’t have clear comments or descriptions, and the fact that these are missing is considerably easier to overlook. Source code control comments can be tricky if you can never delete or edit them.

Re: [webkit-dev] ChangeLog

Maciej Stachowiak wrote: I'm not sure why making an extra copy of the info on update is better than doing it on checkin. People update their tree more often than they commit, so prima facie this seems like a backwards way to do it. Also, svn2cl is much slower than a one-time copy of the latest

Re: [webkit-dev] Iterating SunSpider

Maciej Stachowiak wrote: I think the pauses were large in an attempt to get stable, repeatable results, but are probably longer than necessary to achieve this. I agree with you that the artifacts in "balanced" power mode are a problem. Do you know what timer thresholds avoid the effect? I think

Re: [webkit-dev] Changes to prepare-ChangeLog

with multiple authors? I've been doing this: 2009-07-08 Maciej Stachowiak Make prepare-ChangeLog less shouty https://bugs.webkit.org/show_bug.cgi?id=27098 > Authors: Maciej Stachowiak , Joe Mason Reviewed by Mark Rowe. * Scripts/prepare-Ch

Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)

Maciej Stachowiak wrote: Another note, based on some #chromium conversations: if someone passionate made CMake (or any other tool) into something compelling enough to work better for Chromium than gyp does (or at least to work close-to-as-well), and that tool was more plausible for other ports

Re: [webkit-dev] NeverNull

Eric Seidel wrote: Could get nasty when interacting with other templates though. I don't think we want a NeverNullOwnPtr, or maybe we do? Does this seem useful to anyone else? Oh c++ experts, does this even seem possible, seem like it would perform well, not bloat the code size, etc? Neve

Re: [webkit-dev] Towards a commit-queue

Adam Barth wrote: On Sat, Aug 1, 2009 at 1:13 PM, David Kilzer wrote: Either we should change the review process to only set the review+ flag if the patch is ready to go with zero modifications, or we should use the commit+ flag to signify that. I could go either way on this. I don't like th

Re: [webkit-dev] Calling All Reviewers

Adam Treat wrote: On Friday 07 August 2009 05:51:57 pm Eric Seidel wrote: We also definitely need to fix our tools to make it impossible to post a patch w/o a ChangeLog, and impossible to post a patch that doesn't pass check-webkit-style. This is a bad idea. check-webkit-style still has false

Re: [webkit-dev] Documenting common null pointer errors

Adam Barth wrote: If so, I'm happy to create this with my current knowledge, and hopefully folks with more experience will add parts that I don't know. What's the best medium to make this easy to update in the future? SVG? ASCII art? Sounds very useful. The first tool that springs to mind is

Re: [webkit-dev] Documenting common null pointer errors

Adam Barth wrote: This is now up on the site: http://webkit.org/coding/major-objects.html It's not linked from anywhere yet. It might be a good idea for a couple of folks to look at it. It reflects my understanding of how things work, which might well be wrong. "NULL after navigation" could

Re: [webkit-dev] Dependency tracking in the Qt build system

Mark Rowe wrote: On multiple occasions today we've been forced to manually do a clean build on the Qt build bot in order to work around test failures or crashes caused by bad builds. In the most recent case reordered some virtual methods in Element. T

Re: [webkit-dev] JSC without Dependencies

Steve Falkenburg wrote: On Aug 17, 2009, at 11:04 AM, Brent Fulgham wrote: On Mon, Aug 17, 2009 at 9:19 AM, Brian Barnes wrote: icu*** (might not be possible, google says these are unicode tools) The wtf/unicode things need these libraries. I'm not sure how wise it would be to remove them

Re: [webkit-dev] Should we ever change style guidelines?

Let's try this again now that I've resubscribed with the correct email address: > On Wednesday 09 December 2009 07:52:22 pm Peter Kasting wrote: > > You haven't really said why. The closest you got was the vague "It > is also > > true that the current style guidelines if > > practiced pedanticall

Re: [webkit-dev] PreloadScanner aggressiveness

I don't think every port should be required to implement prioritization and throttling itself - that's just duplication of effort. Maybe there's a good middle-ground, where PreloadScanner is run more often but still does the priority sorting? Joe From: webkit-dev-boun...@lists.webkit.org [ma

[webkit-dev] testing client implementations

I'm not too familiar with the test framework, but my impression is that the LayoutTests are all about the results of page rendering. Are there any tests which validate that callbacks on classes like FrameLoaderClient are called at the expected time? Joe --

Re: [webkit-dev] Cleaning House

> From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel > [e...@webkit.org] > Sent: Thursday, April 04, 2013 9:41 AM > To: Geoffrey Garen > Cc: webkit-dev@lists.webkit.org Development > Subject: Re: [webkit-dev] Cleaning House > > I considered

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

> From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Filip Pizlo > [fpi...@apple.com] > Sent: Saturday, April 13, 2013 12:17 PM > To: Ian Hickson > Cc: dpra...@chromium.org; Benjamin Poulain; webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] Paral

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

> From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Maciej Stachowiak > [m...@apple.com] > Sent: Monday, April 15, 2013 10:05 PM > To: Filip Pizlo > Cc: Benjamin Poulain; webkit-dev@lists.webkit.org; dpra...@chromium.org > Subject: Re: [webkit-dev] Par

[webkit-dev] FrameLoader::stopAllLoaders and sync XHR

I'm trying to debug a deadlock on exit in a BlackBerry app that uses webkit (which is pretty hard to reproduce, so I don't have a cut-down test case yet). Right now my suspicions are on this behaviour: a synchronous XMLHttpRequest starts loading (from a script running in the main frame) Resourc

Re: [webkit-dev] Rewriting binding code generator, maybe?

I could have sworn I saw someone in another thread post that they were interested in taking over maintenance of the binding generators (not necessarily relating to a massive rewrite, just for ongoing maintenance, was my impression). But I can't find that email at all now. Does anyone know who I

Re: [webkit-dev] How to determine the " could cut " status ?

Andy wrote: > Hi, all, > When I select a whole page, I could copy and paste it to other place. > But most of the time I select a page, I'm not allowed to cut it since > the browser does not permit it. So how could I query the status to > determine whether I could copy or cut ? > Editor::canCut

Re: [webkit-dev] Getting more buildbots green

Zan Dobersek wrote: Joe Mason wrote: Maybe the automated regression should run with --random to be sure that dependencies between tests are shaken out. On the other hand, you really want your regression to be deterministic - maybe a second run with --random scheduled once a week or so

Re: [webkit-dev] Getting more buildbots green

David Kilzer wrote: > To me it seems like the result of some tests have impact on the others. This usually indicates some state isn't being reset (in DumpRenderTree or in WebKit) between tests for the GTK+ port. Individual test results should not rely on running previous tests. (The --random