Bug 152689 - konqueror: empty page after logging in in bugzilla
Summary: konqueror: empty page after logging in in bugzilla
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Mandriva RPMs Linux
: NOR grave
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 151769 152186 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-22 10:22 UTC by Nicolas L.
Modified: 2007-11-27 21:05 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Patch (2.68 KB, patch)
2007-11-27 15:05 UTC, Allan Sandfeld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas L. 2007-11-22 10:22:54 UTC
Version:            (using KDE KDE 3.96.0)
Installed from:    Mandriva RPMs
OS:                Linux

Mandriva BugReport: http://qa.mandriva.com/show_bug.cgi?id=35603

Description of problem:
Go to qa.mandriva.com, log in - I get empty window.

It seems that reloading the page fix the pb, but this appears on many websites ( which isn't the case with konqueror from kde3 )
Comment 1 Maksim Orlovich 2007-11-22 20:06:52 UTC
Saw that a few times, not sure about what's going on.. Will give trying to reproduce it a shot..
Comment 2 Maksim Orlovich 2007-11-22 22:27:34 UTC
Potentially related: going to the intro page twice (opening konq, then using help->konqueror introduction) also produces a blank page. The DOM tree looks fine, but there is basically no render tree:

konqueror(10754) khtml::RenderObject::printTree: "" "RenderCanvas(1): 0x84c6910  {0 0} mmk mi zI: auto  <> (0,0,819,504) [0-0] { mT: 0 qT: 0 mB: 0 qB: 0} layer=0x84c69e0"
konqueror(10754) khtml::RenderObject::printTree: "  " "RenderBlock(1): 0x84c6a44  {0 0} ci mmk mi  <html> (0,0,819,0) [0-0] { mT: 0 qT: 0 mB: 0 qB: 0} layer=0x84c6ac8"
Comment 3 Maksim Orlovich 2007-11-22 23:35:19 UTC
Roughly  what happens on second intro page visit:
All attaches are from the parser. HTMLHeadElementImpl and HTMLBodyElementImpl do not get renderer, in the first case because rendererIsNeeded returns false (not sure why yet).

On the first visit, all of the above happens, but also after this it does a recalcStyle due to a stylesheet being loaded:
11: /opt/kde4/lib/libkhtml.so.5(_ZN3DOM12DocumentImpl19updateStyleSelectorEb+0x4e) [0xb427d71e]
12: /opt/kde4/lib/libkhtml.so.5(_ZN3DOM12DocumentImpl16styleSheetLoadedEv+0x5c) [0xb427da7c]
13: /opt/kde4/lib/libkhtml.so.5(_ZN3DOM20HTMLStyleElementImpl11sheetLoadedEv+0x36) [0xb42bd996]
14: /opt/kde4/lib/libkhtml.so.5(_ZNK3DOM17CSSStyleSheetImpl11checkLoadedEv+0x47) [0xb4380d87]
15: /opt/kde4/lib/libkhtml.so.5(_ZNK3DOM13StyleBaseImpl11checkLoadedEv+0x18) [0xb4390948]
16: /opt/kde4/lib/libkhtml.so.5(_ZN3DOM17CSSImportRuleImpl13setStyleSheetERKNS_9DOMStringES3_S3_+0x115) [0xb43855f5]
17: /opt/kde4/lib/libkhtml.so.5(_ZN5khtml19CachedCSSStyleSheet11checkNotifyEv+0x13a) [0xb43b98da]
18: /opt/kde4/lib/libkhtml.so.5(_ZN5khtml19CachedCSSStyleSheet4dataER7QBufferb+0x258) [0xb43be6c8]
19: /opt/kde4/lib/libkhtml.so.5(_ZN5khtml6Loader12slotFinishedEP4KJob+0x178) [0xb43bb608]

.. where stuff is attached fine.
FOUC stuff, may be?
Comment 4 Maksim Orlovich 2007-11-22 23:55:21 UTC
Does indeed appear to be FOUC stuff. Stuck at one pending sheet... Somehow. 
I don't see us noting the loading of the other @import rules. ugh.
Comment 5 Maksim Orlovich 2007-11-23 00:05:32 UTC
Germain: at least the case of blank pages on revisiting the intro page seems to be caused by your r728823. I don't understand the connection between the commit message and the change, either.

Reporter, any chance you could test if commenting out this block:
       if (parentSheet && parentSheet->processed()) {
           parentSheet->doc()->addPendingSheet();
       }
in khtml/css/css_ruleimpl.cpp fixes the problem you're seeing?


Comment 6 Germain Garand 2007-11-23 17:41:47 UTC
re#5: indeed. Thanks for the pointer, I'll have a look later tonight. I'm a bit swamped by other duties atm.

> I don't understand the connection between the commit message and the change,
> either.

the connection is that stylesheets are counted in the document as trees while they are loading. If you add an import rule from script, the stylesheet tree you are adding the rule to will already have been parsed/loaded, so your added sheet need to re-register the whole tree to the document as being in "loading" state. Not sure if that's clear :)
Comment 7 Maksim Orlovich 2007-11-23 18:39:43 UTC
Ah, I see --- I missed the only chunk that changes the grammar itself among the FOUC-avoidance refcounting changes. The thing is, I don't see where we mark stylesheets as loaded here, but I know it's tricky since there is a hiearchy there. I really dislike this stuff, it's brittle and buggy (e.g. in XML).
Comment 8 Allan Sandfeld 2007-11-27 14:32:51 UTC
*** Bug 152186 has been marked as a duplicate of this bug. ***
Comment 9 Allan Sandfeld 2007-11-27 14:48:40 UTC
The same patch that Germain commited also caused regressions in WebKit. Regression fixed with WC#r17825
Comment 10 Allan Sandfeld 2007-11-27 15:05:20 UTC
Created attachment 22220 [details]
Patch

Port of the WC#r17825 regression fix.
Comment 11 Germain Garand 2007-11-27 15:31:02 UTC
Great, thank you for finding that out! I missed that revision.
Please apply at will...

(Changing version to 4.0 so that the release team has a single bugzilla query for tracking remaining blocking issues. 
Using priorities "Grave" for showstopper, "Major" for very serious bug.)
Comment 12 Maksim Orlovich 2007-11-27 19:14:50 UTC
*** Bug 151769 has been marked as a duplicate of this bug. ***
Comment 13 Allan Sandfeld 2007-11-27 21:05:33 UTC
SVN commit 742309 by carewolf:

Follow-up patch to earlier patch ported from WebCore. Fixes Wikipedia and many
other sites.
BUG:152689


 M  +1 -2      css/css_stylesheetimpl.cpp  
 M  +10 -4     html/html_headimpl.cpp  
 M  +2 -2      html/html_headimpl.h  
 M  +1 -1      xml/dom_nodeimpl.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=742309