[webkit-dev] EditBugs permission
Hello, When I submit a patch to bugzilla, I get an error that EditBugs is not set on my account. Can someone add this permission to my bugzilla account please? I sent a message to as instructed, but that doesn't get through. My login is: shezbaig...@gmail.com My patch submitted to: https://bugs.webkit.org/show_bug.cgi?id=80382 Thanks, Shezan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] github mirror
Hi WebKit, I've been using a fork of the following repo: https://github.com/WebKit/webkit However, yesterday there was discussion on #webkit that the SHA-1 checksums on this repo are different from repo at git.webkit.org, which means folks working on both need to have both versions checked out. I believe the answer to this problem is in: http://help.github.com/move-a-repo/ (look at the last section titled "Manual clone and push") Anyone in the "WebKit" organization on https://github.com/WebKit should be able to push this. Once this is pushed, we can retire the existing repo on github. This means the existing forks will be unusable, but I think it will be good to do this earlier rather than later, so we just have "one" repo, and this will make it easier for existing git.webkit.org users to switch to github. Thanks, -shez- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] github mirror
(resending to all) Yes, I think it would be better to mirror git.webkit.org to github instead of mirroring from svn to github. In theory, it really shouldn't make a difference though, so i'm actually surprised that the sha1 are out of sync. But mirroring from git.webkit.org will guarantee they are the same, regardless of any wierdness that git-svn might do. On Wed, Apr 18, 2012 at 10:00 AM, Jarred Nicholls wrote: > Wouldn't we need to continually mirror git.webkit.org to github as well? > I presume github is mirroring directly from svn right now. I'd think the > out-of-sync issue would simply occur again unless we started to mirror > git.webkit.org to github instead of svn to github. > > I don't know what all Git takes into account when creating the sha1 > outside of content, tree and commit meta data, so I'm unsure if doing this > git.webkit.org => github forced push would mean that future svn commits - > being mirrored to both repos in parallel - would result in identical sha1 > hashes going forward...? > > Jarred > > On Wed, Apr 18, 2012 at 6:53 AM, Shezan Baig wrote: > >> Hi WebKit, >> >> I've been using a fork of the following repo: >> https://github.com/WebKit/webkit >> >> However, yesterday there was discussion on #webkit that the SHA-1 >> checksums on this repo are different from repo at git.webkit.org, which >> means folks working on both need to have both versions checked out. >> >> I believe the answer to this problem is in: >> http://help.github.com/move-a-repo/ >> >> (look at the last section titled "Manual clone and push") >> >> Anyone in the "WebKit" organization on https://github.com/WebKit should >> be able to push this. Once this is pushed, we can retire the existing repo >> on github. This means the existing forks will be unusable, but I think it >> will be good to do this earlier rather than later, so we just have "one" >> repo, and this will make it easier for existing git.webkit.org users to >> switch to github. >> >> Thanks, >> -shez- >> >> >> ___ >> 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
Re: [webkit-dev] github mirror
On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann wrote: > > I believe the reason for them being different is because in the github > repo the > commit author fields are resolved. > > That would certainly explain it :) I don't have a git.webkit.org checkout, so I couldn't tell ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Eliminate potential null pointer dereference?
On Fri, Apr 20, 2012 at 3:06 PM, Filip Pizlo wrote: > Someone in this thread said something about code readability. So let's > consider that. If I see code like: > > if (!var) thingy(); > > Then I will be under the impression that var might sometimes be zero and > that thingy() might sometimes happen, and that the previous webkittens to > touch this code had a good reason for this check. > > Coverity is no more accurate than testing; if it tells you that var might be > zero than it cannot, will not, and does not give you 100% confidence that > this is reachable. > > Hence if you add special cases for things that coverity warned you about, > you are potentially doing a disservice to anyone looking at the code in the > future. You are telling them that "var might be zero" when really you meant > to say "I put in this check to get my tool to stop complaining". > > On the other hand, if you are able to construct a test that demonstrates > reachability then you win. But if there is no test then see my previous > paragraph. Wouldn't an ASSERT be more helpful in this case, i.e. something like: ASSERT(var); thingy(); Does ASSERT make coverity stop giving out warnings? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] github mirror
On Tue, Apr 24, 2012 at 9:55 AM, Adam Roben wrote: >> In what situation does this cause issues? > > Probably the biggest issue is for people who've been using > git.webkit.org and now want to try out GitHub. Since the commits are > distinct between the two repositories, they have to do a full clone to > make the switch. In theory though, these users should be able to just add a remote to their existing clone. Then it will just sync the commit objects, and not the trees and blobs. Not ideal, they would have two different 'masters', but still doable, and not *that* much of an overhead. Switching between the different masters should also be fast since the trees will be the same. But I agree these two repos should probably merge sooner rather than later, just to avoid confusion for new users etc :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev wrote:
>
> 19.07.2012, 22:20, "Filip Pizlo" :
>> Now consider the stream form:
>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << "
>> baz " << c << endl;
>> This is 8 procedure calls and three string constants. This code will be
>> somewhere around 8 times fatter. Hence, you will be less likely to want to
>> enable such debug statements in release builds both due to fears concerning
>> unnecessary increases in binary size, and unnecessary increases in compile
>> times.
>
> Well, if all << operators are inline, it will be optimized. You also don't
> have to add endl, because "thingy" can add '\n' and flush buffer at the end
> by default (like qDebug does)
>
Also, if "START_THINGY" and "END_THINGY" are defined as:
#define START_THINGY if (enableDebug) { thingy
#define END_THINGY<< endl; }
Then a statement like:
START_THINGY << "foo " << a << " bar " << someWeirdNonsenseToEnableHex
<< b << " baz " << c << END_THINGY;
will all be wrapped up within an "if (enableDebug)" condition, which
we would only turn on when we need the log output, so the cost of the
streaming/printing can be virtually eliminated even if we decide to
land the code.
This also allows us to do more complex things like:
START_THINGY << "Selectively printing variables:";
if (isSet(someVar1))
thingy << " someVar1 = '" << someVar1 << "'";
if (isSet(someVar2))
thingy << " someVar2 = '" << someVar2 << "'";
if (someArray.length()) {
thingy << " someArray.items = [";
for (int i = 0; i < someArray.length(); ++i) {
thingy << someArray[i] << ", ";
}
thingy << "]";
}
thingy << END_THINGY;
Often when I'm debugging something, I really want to selectively craft
the log message so that I only need to see the variables I'm
interested in, depending on the state of the program *at that time*.
This reduces the clutter in the log message, and since this whole
block is wrapped within "if (enableDebug)", the cost of any additional
work used to generate the log message is completely eliminated if
debug mode is disabled.
And because I'm in the middle of debugging a particular issue, I don't
really want to create a new type that wraps up those (potentially
unrelated) variables, just in order to create an overloaded "debug()"
function that does the pretty printing.
-shez-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Fri, Jul 20, 2012 at 10:53 AM, Shezan Baig wrote:
> On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev wrote:
>>
>> 19.07.2012, 22:20, "Filip Pizlo" :
>>> Now consider the stream form:
>>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << "
>>> baz " << c << endl;
>>> This is 8 procedure calls and three string constants. This code will be
>>> somewhere around 8 times fatter. Hence, you will be less likely to want to
>>> enable such debug statements in release builds both due to fears concerning
>>> unnecessary increases in binary size, and unnecessary increases in compile
>>> times.
>>
>> Well, if all << operators are inline, it will be optimized. You also don't
>> have to add endl, because "thingy" can add '\n' and flush buffer at the end
>> by default (like qDebug does)
>>
>
>
> Also, if "START_THINGY" and "END_THINGY" are defined as:
>
> #define START_THINGY if (enableDebug) { thingy
> #define END_THINGY<< endl; }
>
And we could also wrap these macros with #ifdef ENABLE_THINGY, so even
the compile-time cost is eliminated if we don't want to include thingy
output in our build.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Fri, Jul 20, 2012 at 11:48 AM, Brady Eidson wrote:
> On Jul 20, 2012, at 7:53 AM, Shezan Baig wrote:
>> And because I'm in the middle of debugging a particular issue, I don't
>> really want to create a new type that wraps up those (potentially
>> unrelated) variables, just in order to create an overloaded "debug()"
>> function that does the pretty printing.
>
> I'm not quite sure what your point is here.
>
> - If you mean you don't want to be hassled by added a new template for a
> super long debug statement - debug(a, b, c, d, e, f, g, h, i, j, k, l) when
> the built in utility only supports up through k - then that seems somewhat
> silly as doing so would be simple and mechanical.
>
> - If you mean you don't want to be hassled to add a new overload for the type
> you'd like to print, then you'd still have to add a new operator << overload
> for that type if it didn't already exist.
>
> - If you mean you don't think that debug() statements could be broken up in
> to multiple lines, of course they can.
>
> debug("Selectively printing variables:";
>if (isSet(someVar1))
> debug("someVar1 = ", someVar1);
>if (isSet(someVar2))
> debug("someVar1 = ", someVar1);
>if (someVector.size())
> debug(" someVector.items = ", someVector);
> debug("\n");
>
Yes, this one is pretty much what I meant. My example was a bit
simplified, but I was thinking more along the lines that the code
around the debug() statements could be expensive, for example,
calculating some value from multiple sources and printing the final
result. Within the context of a single function, it might not make
sense to create a separate function that is responsible for
calculating those values, especially if the variables involved are not
typically related.
But your points about readability and such are understood.
Thanks,
-shez-
> Also notice it would be easy to templatize a debug() override to handle the
> pretty-printing of the vector directly, in addition to other POD and
> non-class types.
>
> Even without the vector enhancement, this version is simple easier on my eyes
> as it's not at odds with the entire rest of our code base.
>
> ~Brady
>
>> -shez-
>> ___
>> 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] Disjointed selection ranges
Hi WebKit, We are using embedded WebKit in our application, and we need to be able to use disjointed selection ranges for table editing. I was wondering whether anybody is currently working on implementing this, and is there any bug number for it? If not, I will attempt to implement it based on the approach described by Eric in [1] and [2]. Thanks, Shezan [1] https://bugs.webkit.org/show_bug.cgi?id=15921 [2] https://bugs.webkit.org/show_bug.cgi?id=23793 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disjointed selection ranges
On Tue, Aug 14, 2012 at 3:25 PM, Ryosuke Niwa wrote: > On Tue, Aug 14, 2012 at 11:51 AM, Shezan Baig wrote: >> >> We are using embedded WebKit in our application, and we need to be >> able to use disjointed selection ranges for table editing. I was >> wondering whether anybody is currently working on implementing this, >> and is there any bug number for it? If not, I will attempt to >> implement it based on the approach described by Eric in [1] and [2]. > > > I don't think we should implement general multi-range selection. It causes > all sorts of hell in editing. > > Having said that, I would want to see us supporting proper table editing as > well. What kind of features for table editing do you have in your mind? > Essentially, something like http://jsfiddle.net/4BwGG/14/ Clicking on a table header should select all cells within that column, which in turn should allow me to format the column (e.g. set left/right alignment, change font size etc). > Can we discuss this on public-webapps before proceeding with our > implementation? > Sure, we can discuss it there. But this seems to work fine in other browsers like Firefox, so I figured this was a WebKit-specific issue. Thanks, Shezan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Opera and WebKit
Welcome! I'm very interested in following the multicolumn changes you submitted - in particular the changes for page floats and column spans, but I couldn't find the relevant bugs, Do you happen to have links for those? Thanks, -shez- On Wed, Feb 13, 2013 at 3:06 AM, Håkon Wium Lie wrote: > Dear WebKit community, > > Many of us have met through various web standards efforts, such as > W3C and WHAT WG. Today I'd like to introduce Opera Software in a new > forum for us: the webkit-dev mailing list. > > We have known WebKit and its KTHML predecessor for some time. Lars > Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many > years. TrollTech and Opera shared a building in Oslo, a building which > has earned its place in the rendering engine hall of fame. > > Some of our best programmers have been working on the WebKit code for > a while, and today we have announced that we will be using the WebKit > engine in the future [1]. We will also submit our code; switching from > Presto to WebKit frees up resources and allows us to contribute to the > WebKit platform. > > The first contributions from our side will be in multi-column layout > [2]. We have experimented with combining multicol layout with > page floats and column spans [3]; in 10 lines of CSS code one can > create amazingly beautiful, scaleable and responsive paged > presentations [4]. > > We hope to work with you to further strengthen the open web that we > all believe in. > >[1] http://www.opera.com/press/releases/2013/02/13/ >[2] http://www.w3.org/TR/css3-multicol/ >[3] http://dev.w3.org/csswg/css3-gcpm/#page-floats >[4] http://people.opera.com/howcome/2013/02-reader > > Cheers, > > Håkon Wium Lie > CTO Opera Software > http://people.opera.com/howcome > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 8:32 PM, Peter Kasting wrote: > I question whether it makes sense at all from a user's perspective. Users > don't know or care what classes are used to implement their applications, > they care what the applications do. And from that perspective Windows is > all over the place. Wordpad, Word, and Visual Studio all support overtype > mode, but all three do it differently (Visual Studio is IMO the best -- it > actually changes the cursor from bar to block in overtype mode, which I'd > love to see any other app supporting this to adopt, and certainly would want > if we turned this on in Chrome for Windows). Notepad, which to almost any > user who doesn't open files with LF line endings is the same thing as > Wordpad, doesn't, and neither does Firefox or Chrome (today). Third-party > editors are all over the place. > > I think we should decide this based on what is most helpful and least > confusing to users. Normally a platform convention is a way of establishing > what users will expect, which is why it has any value at all. Here I'm not > convinced there's a user expectation of overtype mode in general, and I > definitely worry that it has low utility and high annoyance, which make me > greatly hesitate. And implementing it for "rich text" but not "plain text" > on the web seems like a recipe for confusion too -- do normal users > understand the distinction and would expect overtype mode in one but not the > other? Seems more likely that some people would be frustrated that overtype > mysteriously doesn't work sometimes, while others would be confused why > every once in a while their text gets eaten, but not in a way they can > reproduce consistently. I feel like I should give some background to this discussion. We are in the process of porting our native Windows application from using a proprietary rendering framework to using WebKit as our rendering framework. Our application is not Chrome, neither is it Safari, Firefox, or Opera. In fact, it isn't a web browser at all. Throughout this effort, we've come across many instances where we have had to modify WebKit in order to make our application work the way our users expect it to. All these changes are maintained in our own private fork, which we frequently merge with upstream. Yes, our users *do* expect overtype mode to work, and yes, we do want a blinking block cursor, however I consider that as an orthogonal setting and not necessarily tied to overtype mode. The way I envisioned this would be that the embedding application would set a property on the contenteditable div to turn on/off the overtype mode, based on some UI interaction (whether it is via the Insert key, or some menu command is up to the application). When the contenteditable is in overtype mode, this essentially makes TypingCommand replace the next character instead of inserting characters. This is a behavior change *only*, not a visual change. When the application switches the overtype mode on/off, it would also at the same time modify the appearance of the cursor (in our app, this will be done via non-standard css properties, like "caret-width" and "caret-color", and yes, we only plan use this for fixed-width fonts). It might also change the border color of the contenteditable. My point is that the visual appearance to indicate that we are in overtype mode is not something I would expect WebKit to control. So I'd rather leave discussion of the appearance separate from the functionality/behavior itself. Regardless of whether WebKit will support overtype mode or not, our application will support it because our users expect it to. However, we want to keep the diff between upstream and our fork to be as small as possible. Also, to me it seems like we would be going against the principle of opensource software if we keep these features in our own private fork only, since it is something that can be useful to the general community. So I guess the question boils down to something like: if we have changes that are generally useful, but not used in the major WebKit applications (i.e. Chrome, Safari, Opera), does it make sense to upstream it to WebKit for the benefit of the general community? Thanks, -shez- ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Tue, Mar 12, 2013 at 12:18 AM, Ryosuke Niwa wrote: >> Have you tested your code with bidirectional text? I don't think using >> block caret will work due to the way offsets at bidi-level boundary works in >> WebKit. In particular, suppose we have, in the document/byte order, ABC123 >> where ABC are strongly RTL letters in a LTR block. Then this text is >> rendered as: >> 123CBA >> >> If we were to place logical/DOM offset at where they appear visually, we >> have: >> (0)1(1)2(2)3C(5)B(4)A(3)(6) > > > Oh oops, I'm sorry. I messed this up. It should be: > (0)1(5)2(4)3C(2)B(1)A(3)(6) > instead. > >> i.e. At offset 3, the caret will visually appear on the right of "A". If >> you were just setting the caret width, the caret will look as if we're >> inserting a character on the right of "A", which is extremely misleading to >> a user. Our application right now doesn't allow for bidi text, so this isn't currently an issue for us. I haven't looked at the details, but if we were to support this in the future, I think the caret rendering code would simply determine whether the next character is RTL or not, and if so, it would extend its width in the opposite direction. Also, I don't understand why offset 3 would be rendered after A -- shouldn't it be rendered before 1 since that is where the next character would be inserted? (or maybe between 3 and C, I'm not familiar enough with the bidi rules). If it is rendered after A right now, then I'm guessing that is just a bug, and whether or not the caret is 1px or 20px wide seems equally misleading to the user. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Fri, Apr 12, 2013 at 6:01 PM, Ryosuke Niwa wrote: > On Fri, Apr 12, 2013 at 10:00 AM, Ryosuke Niwa wrote: >> >> On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin >> wrote: >>> >>> I know that WK follows the NSTextView implementation but FF for example >>> does not show the remote insert issue. >> >> >> Yes, it does. Firefox simply uses heuristics to guess which type of >> character LTR/RTL you're about to type. They still have the same issue. >> >>> > The problem here is that caret will be on top of a wrong character. >>> > That's much worse than a character being inserted at a remote >>> > location. >>> > Using my existing example, what user sees is: >>> > 123CBA or 123CBA >>> > yet what will be replaced is 1. That's insane. >>> > >>> > This is orders of magnitude worse than caret showing up as a vertical >>> > line at this location: >>> > 123|CBA >>> >>> Yeah I understood you example, it was very descriptive. What I wanted to >>> share with you is that, in your same example, in "Insert" mode, placing >>> the caret at (3) will insert the next character before the 1. Isn't that >>> insane too? >> >> >> No. The caret simply shows the logical insertion point. >> >>> > And this is why just setting the width of caret will never work. >>> >>> Well, I have a pretty compact patch more or less ready to be uploaded to >>> bz that in the case of the caret being placed at (3) just draws the >>> classical 1px width bar (it also draws the thin bar in the case of being >>> after the last character), so although the replaced character is in any >>> case the 1, the insanity you mention is somehow minimized. >> >> >> That doesn't sound right either. It's much more confusing than not >> setting any width at all because it's the overtype mode is still on. >> >> What we need to do is here to use selection. We need to have 1-character >> long text selection at all time except at the end of each line when overtype >> is on since selection code already deals with the said bidi craziness. >> Anything short of that isn't landable quality. > > > Of course, we need to pretend as if the selection is collapsed still in > JavaScript APIs. > > - R. Niwa > Wouldn't it be sufficient to just modify CaretBase::updateCaretRect to return a rect that covers the next character? Or am I missing something? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
