User:SadEagle

From KDE TechBase

In-flight stuff

  • Consolidate my other notes
  • Fix innerHTML serialization of script and similar.
    • also in comments
  • show/hide in KHTMLPart
  • relaxing checks in innerHTML, for google.com
    • but need to debug follow up problem with clicks
      • seems to be fixed independently.
    • Need testcase
  • namespace in cloneNode, for the SVG use assert failure
  • click/KHTML_ECMA_CLICK --- and doubleclick cleanup (bug report by pino's brother on openstreetmaps)
  • DOMTS cleanup
  • combobox sizing -- making the popup expand.
  • regtest carewolf's lt patch.
  • scroll, and in general window events (slashdot autoexpand)
    • something more there, too.
  • Java/security exception.
  • caught exception in the JS debugger
  • ID generation? (ade's stuff, xlink namespace)
  • Debug the open-profile/statusbar mess.
  • sidebar dom tree viewer?
  • event handlers not logging exceptions
  • string interning.
  • split domTreeVersion to have structural and specific attribute versions;

make use of that to make ClassNodeList cacheable.

  • implement compareDocumentPosition

Next in queue

  • Performance issues with certificate loading
  • computeContent family of crashes
  • look at the readonly/focus thing again
  • Log various load events, profile stuff.
  • If spart doesn't get to it, / and related stuff --- biggest

stability issue

  • Fix SVG viewport thing
  • Bero had a patch to btoa.cpp
  • Figure out memory management for XHR.
  • new autogen
    • should help with XPath stuff.
    • don't forget bindings stuff
  • multitab thing
  • on google groups: key events with target element being the document.

Current priorities

  • Get for NamedNodeMap
  • new request methods OK'd for XHR
  • For 4.2, do bindings keys, notify kde-bindings/rdale
  • Commit of bug #150843 fix is long overdue
  • Other high-priority bugs:
    • The derstandard.at one
    • In general recursion of tokenizer, scripts. e.g. bug #170765
    • Figure out the selector crash Frank R. testcased, too bug #150662
  • head/body parsing
  • Fix namespacing of WTF
  • Look at google groups again
  • I also had mem-use reduction change for KJS, which had the issue of the global code's lack of body for rewinding. Do we ever run code in GlobalExec, though? We shouldn't...
  • There was also array iteration stuff, not sure it matters, though
  • history/:visited and acid3
  • Fix const stuff
  • The color inheritance stuff... Also, makes me wonder about currentColor --- that's tied in to gcs, though.
    • Spart fixed that and added currentColor parsing in trunk. So with GCS I should be able to add it to canvas.
  • KMail drag icon: http://lxr.kde.org/source/KDE/kdepim/kmail/kmheaders.cpp#2419
  • Something is wrong with abcnews.com

Performance stuff

  • Qt X509 parsing/CA bundle loading
  • setClipRect inefficiency --- report to TT
  • Make khtml use setClipRect less.

Misc stuff

nspluginviewer

  • Debug recent regressions... if I could reproduce it
  • Try to catch Seli about the SuSE/GlibEvents path. Or sic the reporters on the SuSE bugzilla.

Canvas

  • Update for createImageData, range changes
  • Update error handling?
  • setFillColor(double r, double g, double b, double a) extension
  • Can now make width/height reflecting, with ::rewriteValue

KJS and KJS/Frostbyte

  • Idea: don't use hashtables for prototype objects' function fields. This way they can benefit from inline caching
    • Uhm, how do we manage the prototypechain lookup? Seems easier with a type system
  • Idea: function pointers in propertyMap? Makes the map fat, but then can unifty... what? forgot already. Well, certainly getters... Hmm, may be dynamic properties can be handled in the prototype like that, getter-like?
  • Idea: split off the hash table stuff off from JSObject
    • Probably not workable since the prototype even of pure objects can have hashtable properties. Object.prototype doesn't, however, so we can bypass a lot of stuff. Properties there can only be DontEnum or default, too.
  • Debugger, again
    • Mostly works, but stepping through ifs is funny --- need to figure out why
  • Unbreak CPU guard.
  • See if we can keep track of the current function body in the parser. Use that to help track of things like presence of "arguments"
    • With this and eval operator, may be able to get rid of an explicit activation and scope chain entry...
  • Type system changes:
    • Make int32 immediates apply to int32 values --- add a notion of exact embedding
    • Add a notion of value/number dual-use in registers --- use DontMark bit to distinguish which it is
  • Idea: have a template for activation in FunctionImp, and then just memcpy, minus the params, on startup
    • still need to setup functions separately, though.
    • seems slower, actually
  • Idea, part 2: use the above to setup immediates in the same place as registers. This can simplify the IR a lot and shrink the loop considerably. Also means there is no longer architecture differences in 32-bit and 64-bit needs at the IR level, and the IR gets smaller.
    • Of course, recursion more expensive. But worth a try?
  • BUG: need to flush lazy local copies at function call (or do I do it already?)
  • Alternative/conflict with below: if using a single stack for parameter passing/direct calls, we want to always do stack allocation and then do a deferred tearoff when needed --- this may actually be visible based on refcount of the scope chain, except when manually done.
    • That's actually done, but I am not sure of how to best combine it with other stuff
  • Do segmented/nonmoveable stack allocation --- just have a list of pieces, and work on them one at a time. Older ones can be recycled. This means we never have to refetch the locals array.Also avoids the WARNING WARNING WARNING part.
  • Do deferred tearoffs.
  • eval operator/eval tearoffs
    • tearoffs done.
    • With eval operator, if I keep track of lexical depth, may be able to directly route to global object, etc. Needs thought.
  • Fix const
  • obscure sequencing thing
    • seems like an another regression on the TC though --- exception precision?
  • merge in the API, etc., from trunk
  • Do the List performance changes
  • Do IR dialectes for 32- and 64-bit -- e.g. PointerCell
    • Also probably double-allocator for 32-bit.
  • Do a review pass over API to make sure not BC leaks.
  • Double-check global handling, synchronize with JSC
  • Consider using packed immediate/register bits. The key observation is that locals are read from an array, too, so we could do something like:
  arg0 = argsType[(fullOp >> 16) & 1][offsetVal];
  • Crazy idea: when going to proper CFG construction, do we even have to linearize?

KHTML - Short-term stuff

  • Don't forget the leak fixes
    • consult with Maciej and Micha
  • There was a change in getElementsByClassName case behavior
  • Do floating-point font size computation
    • Or rather e-mail it to kfm-devel
  • Fix the damn image-load-event-thing in iframes
  • Go through the canvas testcase again
  • Important, don't know how to fix: bug #163359
  • bug #162745 -- for CSS, we need to strip whitespace from URLs. Ditto for object, I'd think. Perhaps completeURL should do it.
  • For objects, empty URLs should probably embed still -- but when? CompleteURL on empty seems like a culprit for the self-embed bugs.
  • Inherit params
  • JS Redirects
  • Iframe stuff
  • The XHTML parser mode
  • Check the XML parser -- QXML workaround might not be needed, weird whitespace handling and recovery stuff
  • Check the implicit node stuff. Only the form one seems correct to me, and that can be done w/o wasting a bit at top-level.
  • the libthai thing
  • bug #104358
  • XHR:
  • bug #103250 --- KWallet and pages with textareas.

khtmlImLoad

  • Allan's foreign loader patch
  • Scale animation provider for GIF --- bug #162614
  • Animation stoping
  • Better pre-blend cache?
  • FredrikH performance goodness?

KHTML - Long term stuff

Other long term stuff

  • Async loading of nspluginviewer somehow?

Other kdelibs stuff

  • Figure out why the maxProcess stuff in kio_http doesn't seem to work.

KJS game plan

  • Implement eval semantics from ES5 (presumably)
  • Make sure to track down the patch that adds $hint$, lookup stuff, maybe even paste it here to have a backup
  • Scoping issues:
    • think (formalize?) function scope stuff
    • alterations for function literals, catch scope stuff in
    • rework how we handle declarations to avoid visitors?
    • blizzard stage 2 stuff...
    • public hook to cache document?
  • Function call stuff:
    • Get rid of JSObject::call first; or at least move the depth tracking out of it and into Machine (easy, independent)
    • olliej says to push parameters in reverse... think of it some more.
    • look at slimming down ExecState again...
    • change how List works to permit its usage of JS stack.
    • remember the dynamic link/static link distinction: the scope chain is the static link, and can we disconnected, but the dynamic link will always be to parent frame
      • sort of. If one doesn't do a native JS call, one may have to copy stuff over. So essentially it's a 2 case thing: either our stack frame is immediately after, with arguments on the parent frame, or when we do a call from KHTML, etc., we also copy over arguments... in which case, well... i guess we would need two pointers to the frame or something --- one for marking, and one for giving the interpreter?
Retrieved from "https://techbase.kde.org/index.php?title=User:SadEagle&oldid=41921"