Re: [webkit-dev] when updating an inline element, webkit does not redraw the screen until a block-level change happens in the DOM
Hello Simon, As you requested I have reported the bug with a simple testcase: https://bugs.webkit.org/show_bug.cgi?id=116994 Thanks :) Luis On 28 May 2013 10:50, Luis de Bethencourt wrote: > Hello Simon, > > Thanks for the feedback. I will write a simple testcase and report the bug > in the bugzilla. > > Luis > > > On 27 May 2013 17:31, Simon Fraser wrote: > >> I have not heard of this issue. >> >> Please file a bug at bugs.webkit.org with a simple testcase. >> >> Simon >> >> On May 27, 2013, at 2:19 PM, Luis de Bethencourt >> wrote: >> >> Hello all, >> >> When updating an inline element, the browser does not redraw the screen >> until a block-level change happens in the DOM. I have searched around >> online and seen many web developers having this problem and forcing a >> refresh to work around it. By changing the zoom level to 1.1 and back to >> 1.0, by using eloffsetHeight in the element, or with el.hide().show(). >> >> I presume this is a known issue due to performance optimizations, but I >> can't find a related bug in bugzilla. >> >> Is this issue known and has it been reported? >> >> Thanks, >> Luis >> ___ >> 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] when updating an inline element, webkit does not redraw the screen until a block-level change happens in the DOM
Hello Simon, Thanks for the feedback. I will write a simple testcase and report the bug in the bugzilla. Luis On 27 May 2013 17:31, Simon Fraser wrote: > I have not heard of this issue. > > Please file a bug at bugs.webkit.org with a simple testcase. > > Simon > > On May 27, 2013, at 2:19 PM, Luis de Bethencourt > wrote: > > Hello all, > > When updating an inline element, the browser does not redraw the screen > until a block-level change happens in the DOM. I have searched around > online and seen many web developers having this problem and forcing a > refresh to work around it. By changing the zoom level to 1.1 and back to > 1.0, by using eloffsetHeight in the element, or with el.hide().show(). > > I presume this is a known issue due to performance optimizations, but I > can't find a related bug in bugzilla. > > Is this issue known and has it been reported? > > Thanks, > Luis > ___ > 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
[webkit-dev] when updating an inline element, webkit does not redraw the screen until a block-level change happens in the DOM
Hello all, When updating an inline element, the browser does not redraw the screen until a block-level change happens in the DOM. I have searched around online and seen many web developers having this problem and forcing a refresh to work around it. By changing the zoom level to 1.1 and back to 1.0, by using eloffsetHeight in the element, or with el.hide().show(). I presume this is a known issue due to performance optimizations, but I can't find a related bug in bugzilla. Is this issue known and has it been reported? Thanks, Luis ___ 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?
Hello Sergio, I personally find overtype a very useful tool in vim/emacs, but it is funny how half the links in the first page of Google results to "overtype" are about turning it off. That said, it is an interesting tool that all major text editors support, useful if you want to use it and easily ignored if you don't. Luis On Mar 11, 2013 12:06 PM, "Sergio Villar Senin" wrote: > Hi, > > I was wondering if WebKit as a project would be interested in having > overtype mode support for editable content. This in indeed the mode in > which the cursor, when typing, overwrites any text that is present on > and after its current location [1]. > > Looks like something like that could be useful to implement online > editing tools. Just for reference, both IE and Opera support it while in > Firefox the bug was closed as WONTFIX [2] after a lot of discussion. > > Thoughts? > > [1] http://en.wikipedia.org/wiki/Insert_key > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=38415 > ___ > 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] Should we create an 8-bit path from the network stack to the parser?
On Mar 7, 2013 10:37 PM, "Brady Eidson" wrote: > > > On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff wrote: > >> The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. > >> > >> My research showed that at the time showed that there were very few UTF-16 only resources (<<5% IIRC), although I expect the number to grow. > > On Mar 7, 2013, at 2:16 PM, Adam Barth wrote: > > Yes, I understand how the HTML tokenizer works. :) > > I didn't understand these details, and I really appreciate Michael describing them. I'm also glad others on the mailing list had an opportunity to get something out of this. > > ~Brady I agree with Brady. I got some interesting learning out of this thread. Always nice to read explanations and documentation about how things work. Valuable content. Luis > > ___ > 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
