September 2010 - webkit-dev - lists.webkit.org

bugs.webkit.org autocomplete
by Adam Barth 15 Sep '10

15 Sep '10

Hi webkit-dev, I just landed a change to bugs.webkit.org to autocomplete email address for committers and reviewers. If you've been using Ojan's awesome extension, it's the same code, just now natively part of bugs.webkit.org thanks to William Siegrist being awesome. (Note that if you have the extension installed, you'll probably want to uninstall it so that it doesn't fight with the native feature.) Let me know if you have feedback on the feature. If you notice that it's missing someone or has the wrong email address, please update http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/co…. The autocomplete list will update automagically instantly. Adam

3 2

Re: [webkit-dev] Canvas performance and memory usage
by Martin Robinson 14 Sep '10

14 Sep '10

Resent from the proper address: On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson <martin.james.robinson(a)gmail.com> wrote: >> I notice that Qt added imageForRendering() and felt they could not use >> image() for some reason. I'd be curious if a Qt expert could weigh in on >> that, since maybe with a redesign a separate call would not be needed. I'm not a Qt expert, but just based on a quick look, it seems that imageForRendering avoids the full QPixmap copy. Christophe, when you open a bug for this issue, please CC me, as I have a small patch in my tree which has the same imageForRendering pecialization, but for Cairo. Martin

8 15

Re: [webkit-dev] Bug system: Platform and OS fields don't quite align
by Ryosuke Niwa 14 Sep '10

14 Sep '10

On Tue, Sep 14, 2010 at 10:38 AM, Jeremy Orlow <jorlow(a)chromium.org> wrote: > > It's worth noting that Android also uses v8 and skia. They only have one > reviewer at the moment, but it still might be best to not associate Chromium > with skia/v8 changes. > > As for the original questions: does anyone actually use any of those > categories in bugs? If not, is there any way to get rid of them? As far as > I'm aware, they're just noise at the moment. > You mean Platform & OS? I've seen dozens editing bugs that are associated with Windows or Mac since some behaviors need to be platform-specific or there are platform-specific quirks. I've never really seen a good use of Platform because platform is usually determined by OS. I'd like to see qt, gtk, chromium, etc... on platform (or better be called as ports?) instead. - Ryosuke

1 0

Bug system: Platform and OS fields don't quite align
by Mike Belshe 14 Sep '10

14 Sep '10

Hi, I tend to hit code which is often chromium-platform specific. It's hard to know the appropriate "Platform" and "OS" fields for such a bug. For instance, I am working on a small change to WebKit/chromium/src/WebKit.cpp. It's not a Mac bug, its not a PC bug, its a Chromium bug. Chromium is a platform of sorts. Chromium bugs could be OS-specific (like Windows, MacOS, etc). So I think the platform field would be the right place to surface such a thing. Should the bug system surface a platform for Chromium? If so- perhaps there are other platforms to surface as well. I'm not sure when a particular flavor of webkit warrants a field in the bug system. If we aren't willing to reflect this through the bug system, what are the right values for these fields? I'm guessing the apple guys want to filter out these bugs - how do you do it today? Thanks, Mike

4 3

Use of Frame by ResourceHandle
by Adam Barth 14 Sep '10

14 Sep '10

I don't mean to spam this list with design questions, but I'm trying to wrap my mind around how the loader is put together today and how we'd like it to be put together in the future. There's a FIXME in ResourceHandle that says that ResourceHandle shouldn't depend on Frame. (For those who aren't familiar with the loader, ResourceHandle is the primary platform abstraction WebCore uses to communicate with the network.) This makes sense to me for two reasons: 1) ResourceHandle is in WebCore/platform/network and therefore isn't allowed to depend on parts of WebCore outside the platform directory. 2) There are a number of types of network requests that are not associated with frames (e.g., XMLHttpRequests from WebWorkers, PingLoader, etc). Do we still believe this FIXME is accurate? If so, I have some time next week to look at removing the dependency. There's a patch that either recently landed or is about to land that furthers the use of Frame by ResourceHandle, so I wanted to check with folks more broadly about whether this is the right direction. (Note that I haven't studied the code yet, so I'm not sure what would be required to remove the dependency.) Adam

6 19

Why is ResourceHandle.cpp in WebKit/chromium/src
by Adam Barth 13 Sep '10

13 Sep '10

In investigating the loader, I noticed that Chromium's ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a WebCore/platform abstract. Most of the other implementations of ResourceHandle are in WebCore/platform/mumble/ResourceHandleMumble.cpp. Is there a reason why Chromium uses a different design? Normally, we need a use a virtual function to jump from WebCore to WebKit/chromium. It looks like we're avoiding that in this case, at the cost of blurring the layer boundaries. Adam

4 7

Leopard Debug and Windows Debug test bots are too slow
by Ryosuke Niwa 10 Sep '10

10 Sep '10

Hi, It came to my attention that Leopard Debug (Tests) and Windows Debug (Test) are always behind by a significant amount (5-10 hours). Since Leopard and Windows are two major platforms we support, I would like to know when my patch broke these two platforms. However, because these two bots are 5-10 hours behind, it's really hard for me to realize any brokerage I caused or follow up later because even if I attempted a fix, I won't see the results for another 5-10 hours. Is there anyway we can upgrade these two bots so that it won't be a burden for WebKit developers? Best, Ryosuke Niwa Software Engineer Google Inc.

3 4

SIL Open Font License and WebKit
by Alex Milowski 10 Sep '10

10 Sep '10

We have a licensing issue we need to address for MathML. We need the STIX fonts as they will provide consistent rendering for Mathematics. I highly suspect these fonts will find themselves on our desktops somewhere down the road. Meanwhile, we need them for our testing infrastructure to actually work across all the platforms. The STIX Fonts are available under the SIL Open Font License: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=OFL_web You can see the patch that adds these fonts here: https://bugs.webkit.org/show_bug.cgi?id=41961 I think we need to adjust our licensing policy to include font licenses like the above. It is unlikely that the STIX consortium will change their font licensing. In reality, they don't need to do so. The font license is intended to support "open source" fonts. -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics

8 20

Re: [webkit-dev] [webkit-changes] [67188] trunk/WebKit/chromium
by Alexey Proskuryakov 10 Sep '10

10 Sep '10

Do we know why this (incorrect commit messages) happens? With the new support for committer name rewriting, this has become even more confusing. - WBR, Alexey Proskuryakov 10.09.2010, в 4:36, darin(a)apple.com написал(а): > Revision > 67188 > Author > darin(a)apple.com > Date > 2010-09-10 04:36:40 -0700 (Fri, 10 Sep 2010) > Log Message > > 2010-09-08 Darin Adler <darin(a)apple.com> > > Reviewed by Adam Barth. > > Move functions from Frame to Editor as planned > https://bugs.webkit.org/show_bug.cgi?id=45218 > > * src/ContextMenuClientImpl.cpp: > (WebKit::selectMisspelledWord): > (WebKit::ContextMenuClientImpl::getCustomMenuFromDefaultItems): > * src/WebFrameImpl.cpp: > (WebKit::WebFrameImpl::find): > (WebKit::WebFrameImpl::stopFinding): > (WebKit::WebFrameImpl::scopeStringMatches): > * src/WebViewImpl.cpp: > (WebKit::WebViewImpl::caretOrSelectionBounds): > Changed call sites to use editor(). > Modified Paths > > trunk/WebKit/chromium/ChangeLog > trunk/WebKit/chromium/public/WebDOMEvent.h > Diff > > Modified: trunk/WebKit/chromium/ChangeLog (67187 => 67188) > > --- trunk/WebKit/chromium/ChangeLog 2010-09-10 10:57:49 UTC (rev 67187) > +++ trunk/WebKit/chromium/ChangeLog 2010-09-10 11:36:40 UTC (rev 67188) > @@ -53,13 +53,22 @@ > * src/WebKit.cpp: > (WebKit::areLayoutTestImagesOpaque): Make linux match windows. > > +2010-09-10 Jay Civelli <jcivelli(a)chromium.org> > + > + Reviewed by Darin Fisher. > + > + Add the destructor to WebDOMEvent to prevent a leak. > + https://bugs.webkit.org/show_bug.cgi?id=45287 > + > + * public/WebDOMEvent.h: > + (WebKit::WebDOMEvent::~WebDOMEvent): > + > 2010-09-09 Chris Guillory <chris.guillory(a)google.com> > > Reviewed by Chris Fleizach. > > Add methods used to determine accessibility state. > https://bugs.webkit.org/show_bug.cgi?id=45434 > - > > * public/WebAccessibilityObject.h: > * src/WebAccessibilityObject.cpp: > Modified: trunk/WebKit/chromium/public/WebDOMEvent.h (67187 => 67188) > > --- trunk/WebKit/chromium/public/WebDOMEvent.h 2010-09-10 10:57:49 UTC (rev 67187) > +++ trunk/WebKit/chromium/public/WebDOMEvent.h 2010-09-10 11:36:40 UTC (rev 67188) > @@ -50,6 +50,8 @@ > BubblingPhase = 3 > }; > > + ~WebDOMEvent() { reset(); } > + > WebDOMEvent() : m_private(0) { } > WebDOMEvent(const WebDOMEvent& e) : m_private(0) { assign(e); } > WebDOMEvent& operator=(const WebDOMEvent& e) > _______________________________________________ > webkit-changes mailing list > webkit-changes(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes

3 2

IFRAME content displaying outside boundaries when transition applied (also CVE-2010-1757)
by Rob Barreca 10 Sep '10

10 Sep '10

If you load http://farm.rob.sproutinc.com/webkit.problem.iframe.html in iOS 3.1.3 and earlier and click on the gray <div>, the content will jump outside of the IFRAME's bounds right when the WebKit Transition is applied. I searched high and low and found CVE-2010-1757 which fixed a security bug that now prevents this in 3.2+. But, the problem is that we are not intentionally trying to show content outside the IFRAME, we want the content to stay inside the IFRAME; we are only triggering a fade out transition. Does anyone know of a workaround that we can apply on the HTML-side to prevent this prison break from happening in 3.1.3 and earlier? (Sorry if this isn't an appropriate place to ask this question.) > From http://support.apple.com/kb/HT4225 WebKit CVE-ID: CVE-2010-1757 Available for: iOS 2.0 through 3.1.3 for iPhone 3G and later, iOS 2.1 > through 3.1.3 for iPod touch (2nd generation) and later Impact: Websites with embedded iframe elements may be vulnerable to user > interface spoofing Description: Safari allows an iframe element to display content outside its > boundaries, which may lead to user interface spoofing. This issue is > addressed by not allowing iframe elements to display content outside their > boundaries. Credit to Wayne Pan of AdMob, Inc. for reporting this issue. Thanks, -- Rob Barreca Director of Development Sprout, Inc. Mobile: 808.224.1905 Confidential and Proprietary Property of Sprout; Do not distribute. The information contained in this email is confidential. This information is intended for use only by the individual to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication and its contents is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email and attachments, and destroy all copies.

1 1