WebKit worklist

WebKit is an HTML rendering library. Linden Lab is working with Torch Mobile to integrate QtWebKit into Second Life, and using this page to coordinate work

Work items

Ad hoc punchlist for coordinating between Torch Mobile and Linden Lab

To Do (Torch):

• High priority
• Medium
  • ::pump() method on OSX never returns! Monroe's workaround to this is to not call pump(), but that's not good.
  • ::pump() method - and llbrowser - should be using a private event loop, not the 'main' Qt/glib event loop
  • llbrowser api extension to let app handle dialog/alert display and policy, async (or - a neat way to have dialogs draw into only the corresponding web view)

    • LLMozLib has been modified to no longer popup modal dialogs, but simply spit out a message to the console until the api is in place.

  • Why are scrollbars on OS X black? (is this theme-specific? if so, forcing a known-good Qt theme is acceptable for now, we do not need to look 'native') (tested on 4.4 + 4.5) http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=218271
  • white blinking between pages - setBackgroundColor not doing everything that was intended - are we showing the 'blank' page for a frame? investigate+debug (tofu sent trace debug log to icefox)

A patch has been applied to llmozlib, need to confirm while running in SecondLife - Works some of the time, *needs more work*.

• Low
  • If we had a magic Flash plugin that worked inside a QWebView inside a QGraphicsView on at least one platform, how would we enable it (where would we put it so it would be found, etc)?
  • Write up some autotests to verify behavior (1/2 done)
• Future
  • Expose the Qt4.5 webkit page-scaling API through llbrowserlib
  • Per-webpage-view event-loops / ::pump(ms) so the app can decide timeslices per-webpage
  • Per-webpage-view stylesheet overrides

To Do (Linden Lab)

• Confirm that we'd like to rename to llbrowser, integrate with mozilla into one branch
• Define the behavior of reset

Done:

• • http://writer.zoho.com/jsp/home.jsp?serviceurl=%2Findex.do complains that we don't support cookies

Patch for QtWebKit has been filed upstream here: https://bugs.webkit.org/show_bug.cgi?id=24062
Patch has been reviewed and was merged into Webkit.

• • Add api to llmozlib to change the cursor so llmozlib can request cursor changing when over a link
  • LL - Using the document steps for building qt from scratch on Win32 build it and then building llmozlib (+bootstrap Callum)
  • LL - Build the Second Life viewer, integrating QtWebKit (Win32)
  • win32 and linux vertical scrollbars have horizontal arrows (screenshot:Media:Webkitvbar.png) this looks fixed now on linux, need confirmation on win32 (Confirmed fixed internally as of webkit-4 r114426 Media:Webkitvbar_fix_win32.png)
  • combo form widgets create top-level OS window. This isn't ideal for a few reasons. again, llbrowser api extension to let the app build/display/dispatch these widgets
  • Make a patch for Qt, some cookies have invalid expiration dates, qnetworkcookie was rejecting the entire cookie rather then paring the date.
  • Make a patch for Qt, gmail.com loaded twice shows a 301 html page rather then redirecting
  • Yahoo.com complains because of our user agent
  • Make https:// sites work on Windows using shared library version of OpenSSL

QtWebKit build instructions have been updated with initial instructions for building Qt with openssl support

• • Remove dependency on Qt build location for accessing image format plugins.
  • We can use QCoreApplication::addLibraryPath to specify additional locations besides Qt's build directory. What directory should be specified?
    • The componentDir parameter to LLMozLib::init() should be used to specify this.
  • Tell qt that it can find the image plugins in component_directory/imageformats/
  • On Windows append d to the library name when build in debug mode
  • Build debug and release versions of qt webkit libraries and dll's, and working versions of uBrowser and TestGL on Win32 platform.
  • Patch QtWebKit to get the target string on a link (or... some other solution).

    A solution has been put upstream and will be part of Qt 4.6. For now a patch exists in llmozlib2

  • LL - Build the Second Life viewer, integrating QtWebKit (OSX)
  • Space bar doesn't insert a space in text fields.
  • Save Cookie Jar
  • bug: WebpageIcons.db is getting written into the SL viewer's bin dir (which we're supposed to be treating read-only).
  • issue: where is the webkit cache (and cookiejar) being written to? it doesn't look like it's going to e.g. ~/.secondlife/browser_profile as we request of mozilla, changed to use the profile_directory
• LL - Export WIP branch for QtWebKit
• LL - Build the Second Life viewer, integrating QtWebKit (Linux)
• LL - Define the behavior of setBackgroundColor (done - but still not working as intended? - outstanding 'white blinking' issue)
• LL - Define the behavior of the cookiejar on exit (done - cookies should be saved)
• llbrowser api extension for explicit pumping of qapplication events (ideally limited by msec - qt offers this api); either per-context pumping or a llbrowserlib-wide pump, your call for now.
• CookieJar, The default Qt cookie jar does not work on all sites. A better cookie jar is needed. (done)
• Win32 Binaries for QtWebKit
• Windows readmes and assistance
• Update readme's
• switch to using stdint.h like in the chromium branch rather then ints defined by different libraries (moz, qt, etc). Any objections?
• The cache is being written inside the application bundle on the Mac. The current mozilla implementation puts it in ~/Library/ Application Support/SecondLife/browser_profile (along with some other mozilla-specific stuff), but a more appropriate place would probably be in a subdirectory of ~/Library/Caches/SecondLife.

Priority guidelines:

• "High"
  • There should be no more than one or two issues per active developer marked as "high" at any given time.
• "Medium"
  • Candidates for bumping to high priority. Attempt to keep this list in priority order
• "Low"
  • Nice-to-have features and fixes that would be ok to leave in place for a First Look (beta) release.
• "Future"
  • Nice-to-have features and fixes that are only relevant to a future milestone