Projects/KHTML: Difference between revisions
< Projects
No edit summary |
|||
| Line 2: | Line 2: | ||
* 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) | ||
** head/body parsing : {{Bug|170694}} ? | ** head/body parsing : {{Bug|170694}} ? | ||
=== Acid3 stuff === | === Acid3 stuff === | ||
| Line 27: | Line 24: | ||
=== Potentially high-impact bugs === | === Potentially high-impact bugs === | ||
* {{Bug|150662}} | * {{Bug|150662}} | ||
* 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. | ||
*** I analyzed this some more, and it's very hard to fix; basically the whole restoreState on multiple frames thing is broken, as it tries to restore kids independently of parents, and each may have <script> fragments, etc. The code likely needs to be reworked to do deferred application of saved info such as scroll position, etc., once loaded. -Maks | *** I analyzed this some more, and it's very hard to fix; basically the whole restoreState on multiple frames thing is broken, as it tries to restore kids independently of parents, and each may have <script> fragments, etc. The code likely needs to be reworked to do deferred application of saved info such as scroll position, etc., once loaded. -Maks | ||
Revision as of 22:29, 18 November 2008
In-progress bugfixes
- SadEagle:bug #169988 --- focus/blur on all elements, head/body parsing #?????, multiple problems with onchange (bug #170451, many others)
- head/body parsing : bug #170694 ?
Acid3 stuff
See Projects/Acid3
Major targets
- SVG --- vtokarev
- DOM namespace changes --- vtokarev --- done (in trunk)
- Class attribute hashconsing for improved css selectors performance --- vtokarev
- Implementation that we have currently is significantly slower on specific test case (probably less on real-life pages). Anyway, it should improve performance (maybe even memory usage), with small drawback on complexity
- HTML5 Audio/Video --- Spart
- getComputedStyle w/display:none --- SadEagle
- Acid3 #35/#41, bug #169617
- 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
- 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.
- I analyzed this some more, and it's very hard to fix; basically the whole restoreState on multiple frames thing is broken, as it tries to restore kids independently of parents, and each may have <script> fragments, etc. The code likely needs to be reworked to do deferred application of saved info such as scroll position, etc., once loaded. -Maks
- 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.