Projects/KHTML: Difference between revisions

From KDE TechBase
No edit summary
No edit summary
Line 1: Line 1:
=== In-progress bugfixes ===
=== In-progress bugfixes ===
* SadEagle:{{Bug|169988}} --- focus/blur on all elements, head/body parsing #?????, multiple problems with onchange ({{Bug|170451}}, many others)
* SadEagle:{{Bug|169988}} --- focus/blur on all elements, head/body parsing #?????, multiple problems with onchange ({{Bug|170451}}, many others)
** onchange on lineedit/textarea isn't called because handleFocusOut isn't called for redirected widgets
* RTL application (-reverse) fixes
*** would something like http://rafb.net/p/ikWvHK97.html do? I didn't actually tested the patch for lack of a testcase though.(Sp.)
* make frame resizing dynamical - possibly with a frame indicator.
****seem to work fine so I'll go ahead... (Sp.)
* working on integrating changes in 4.1.2 ChangeLog (Sp.)
** Woops, done that already. Sorry. -Maks.
*** bah, nevermind... I'm too slow. Thank you.(Sp.)
* need to add/update several testcases in regression suite for 4 or 5 five bug fixes (Sp.)
* need to add/update several testcases in regression suite for 4 or 5 five bug fixes (Sp.)


* I have a patch for doing dns-prefetch as was suggested on http://www.kdedevelopers.org/node/3701#comment-8086 , however I'm not sure what's the policy for sharing of private interfaces between sub directories of kdelibs... may I just #include <kio/hostinfo_p.h> or should this interface be made public first?  (Sp.)
* I have a patch for doing dns-prefetch as was suggested on http://www.kdedevelopers.org/node/3701#comment-8086
** At the very least it'd need to have the class exported via the KIO_EXPORT macro
** Maksim, to answer your question, the point is not to retrieve on hover but as soon as an anchor's href is parsed, so it is wasteful, but the Chromium guys say they observe it doesn't put a significant pressure on DNSes as the average page as few external links. My approach would be to cap the number of resolution to something (configurable) like 40 per page, getting most of the benefit on news site, without the DDOSing behaviour. It does give a kind of "what could possibly go wrong" feeling though :-)


=== Acid3 stuff ===
=== Acid3 stuff ===
Line 31: Line 27:
=== Potentially high-impact bugs ===
=== Potentially high-impact bugs ===
* {{Bug|150662}}
* {{Bug|150662}}
* Selection crashes, affecting at least Kopete {{Bug|170749}}, seen elsewhere, too (I believe I fixed this some times ago.. r855319 {{Bug|167239}} - needs test (Spart))
* derstandard.at
* derstandard.at
* tokenizer script-recursion crashes - (what bug #? (Spart))
* tokenizer script-recursion crashes - (what bug #? (Spart))
** Might not be a good name, but I mean: {{Bug|170185}}, part of {{Bug|165601}}, part of {{Bug|162498}}, later bts and dupes of {{Bug|145666}}, and likely some others. My initial description is probably wrong, though --- the problem is the hack in handling window.document that creates the document by calling begin/write/end is doing so on a document with a parser active; one of the triggers is probably because the restoration of frames from KHTMLPageCache may happen in the wrong order, but the various reports suggest it's not the only case. (The reason for the original description is that I recalled seeing quite a few reports mentioning the same m_scriptExecuting assert, e.g. {{Bug|118104}} for a long time, and figured it's time to get rid of this; some of those are actually mixed in with the dupes of the above). -S.E.
** Might not be a good name, but I mean: {{Bug|170185}}, part of {{Bug|165601}}, part of {{Bug|162498}}, later bts and dupes of {{Bug|145666}}, and likely some others. My initial description is probably wrong, though --- the problem is the hack in handling window.document that creates the document by calling begin/write/end is doing so on a document with a parser active; one of the triggers is probably because the restoration of frames from KHTMLPageCache may happen in the wrong order, but the various reports suggest it's not the only case. (The reason for the original description is that I recalled seeing quite a few reports mentioning the same m_scriptExecuting assert, e.g. {{Bug|118104}} for a long time, and figured it's time to get rid of this; some of those are actually mixed in with the dupes of the above). -S.E.
* QWidget::scroll bug ({{Bug|167739}}) - ouch, I just discovered the BR and the analysis... that explain why the performance was so low on random pages. Need to use QWidget::scroll with a rect argument on Scrollarea's widget(), but also need to fix the associated Qt bug/inefficiency - doing that now (S.)
** solved - will prepare a qt-copy patch
* Sometimes changing pages doesn't repaint properly, leaving parts of the old one. I've seen it on lists.kde.org, but can't reproduce now , here is one reproducible (r855004 on branch)testcase, though (but this one uses frames, not standalone) (-S.E.):
* Sometimes changing pages doesn't repaint properly, leaving parts of the old one. I've seen it on lists.kde.org, but can't reproduce now , here is one reproducible (r855004 on branch)testcase, though (but this one uses frames, not standalone) (-S.E.):
** 1. Go to http://www.cs.cornell.edu/courses/cs3810/2008fa/
** 1. Go to http://www.cs.cornell.edu/courses/cs3810/2008fa/
Line 42: Line 35:
** 3. Scroll down.
** 3. Scroll down.
** 4. Click on Grading/HW again -- much of the frame isn't repainted
** 4. Click on Grading/HW again -- much of the frame isn't repainted
*** fixed in my tree, thanks for the nice test case (Sp.)

Revision as of 13:23, 9 October 2008

In-progress bugfixes

  • SadEagle:bug #169988 --- focus/blur on all elements, head/body parsing #?????, multiple problems with onchange (bug #170451, many others)
  • RTL application (-reverse) fixes
  • make frame resizing dynamical - possibly with a frame indicator.
  • need to add/update several testcases in regression suite for 4 or 5 five bug fixes (Sp.)
  • I have a patch for doing dns-prefetch as was suggested on http://www.kdedevelopers.org/node/3701#comment-8086
    • Maksim, to answer your question, the point is not to retrieve on hover but as soon as an anchor's href is parsed, so it is wasteful, but the Chromium guys say they observe it doesn't put a significant pressure on DNSes as the average page as few external links. My approach would be to cap the number of resolution to something (configurable) like 40 per page, getting most of the benefit on news site, without the DDOSing behaviour. It does give a kind of "what could possibly go wrong" feeling though :-)

Acid3 stuff

See Projects/Acid3

Major targets

  • SVG --- vtokarev
  • DOM namespace changes --- vtokarev
  • HTML5 Audio/Video --- Spart
  • getComputedStyle w/display:none --- SadEagle
  • iframe stuff --- SadEagle, non-immediate
    • XSS permissions for about: and javascript: URL affect tinyMCE
  • canvas --- SadEagle, non-immediate:
    • New params to putImageData, createImageData, parameter checking updates
    • Depends on getComputedStyle:
      • Add support for currentColor
      • text

Potentially high-impact bugs

  • bug #150662
  • derstandard.at
  • tokenizer script-recursion crashes - (what bug #? (Spart))
    • Might not be a good name, but I mean: bug #170185, part of bug #165601, part of bug #162498, later bts and dupes of bug #145666, and likely some others. My initial description is probably wrong, though --- the problem is the hack in handling window.document that creates the document by calling begin/write/end is doing so on a document with a parser active; one of the triggers is probably because the restoration of frames from KHTMLPageCache may happen in the wrong order, but the various reports suggest it's not the only case. (The reason for the original description is that I recalled seeing quite a few reports mentioning the same m_scriptExecuting assert, e.g. bug #118104 for a long time, and figured it's time to get rid of this; some of those are actually mixed in with the dupes of the above). -S.E.
  • Sometimes changing pages doesn't repaint properly, leaving parts of the old one. I've seen it on lists.kde.org, but can't reproduce now , here is one reproducible (r855004 on branch)testcase, though (but this one uses frames, not standalone) (-S.E.):
Retrieved from "https://techbase.kde.org/index.php?title=Projects/KHTML&oldid=34317"