| Summary: | Reading freemail.hu webmail is broken (Regression) | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | András Manţia <amantia> |
| Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | finex, hopparz, maksim |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | framebug.tar.bz2 | ||
|
Description
András Manţia
2005-06-03 20:41:26 UTC
Well, the bug is still present and the username above is not valid anymore. If anyone cares to fix it, I will create a new user. This is a very annoying bug for Hungarian users... then please do, yes... The same user/pass should work again. The problem is still present in 3.5 from svn. I've tried to find the
reason (create a small testcase), but I wasn't quite successful. I have
a guess though which might indicate that the problem is JavaScript
interpretation related. If you click onto the "Olvas" link in the left
menu, a page called "readnavig?sid=LONGSTRING" is opened in the right
frame with the following (or similar) content:
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
if ( top.current_mmax == 0 ) top.current_mmax = 5
if ( top.current_page == 0 ) top.current_page=((5-1)/top.pagesize)+1;
if ( top.current_msgnum == 0 ) top.current_msgnum=5;
if ( top.current_read_msgnum == 0 ) top.current_read_msgnum=5;
if ( top.current_fullfolder != 0 )
document.location.href='folder_m?sid=0acAy1Dh0EMmbTvyXpSm2PU3lK8Of7iyw48ZuYIjRbOnFi2YQecNL0O3j5zQ3GGEv0s5QT6jeKec_';
if ( top.current_fullmail != 0 )
document.location.href='read_m?sid=0acAy1Dh0EMmbTvyXpSm2PU3lK8Of7iyw48ZuYIjRbOnFi2YQecNL0O3j5zQ3GGEv0s5QT6jeKec_&folder='
</SCRIPT>
</HEAD>
<frameset ROWS="145,*" FRAMESPACING="0" BORDER="0" FRAMEBORDER="no">
<frameset COLS="230,*" FRAMESPACING="0" BORDER="0"
FRAMEBORDER="no">
<frameset ROWS="35,*" FRAMESPACING="0" BORDER="0"
FRAMEBORDER="no" BORDER="0">
<frame NAME="folders_top"
SRC="folders_top?sid=0acAy1Dh0EMmbTvyXpSm2PU3lK8Of7iyw48ZuYIjRbOnFi2YQecNL0O3j5zQ3GGEv0s5QT6jeKec_"
MARGI
<frame NAME="folders"
SRC="folders?sid=0acAy1Dh0EMmbTvyXpSm2PU3lK8Of7iyw48ZuYIjRbOnFi2YQecNL0O3j5zQ3GGEv0s5QT6jeKec_"
MARGINHEIGHT=
</frameset>
<frame NAME="folder_m"
SRC="folder_m?sid=0acAy1Dh0EMmbTvyXpSm2PU3lK8Of7iyw48ZuYIjRbOnFi2YQecNL0O3j5zQ3GGEv0s5QT6jeKec_"
MARGINHEIGHT="0" MA
</frameset>
<frame NAME="read_m"
SRC="javascript:this.document.location.href='read_m?sid=0acAy1Dh0EMmbTvyXpSm2PU3lK8Of7iyw48ZuYIjRbOnFi2YQecNL0O3j5zQ3GGEv0s5QT
</frameset>
</HTML>
It seems that in Konqueror
if ( top.current_fullmail != 0 )
document.location.href='read_m?sid=0acAy1Dh0EMmbTvyXpSm2PU3lK8Of7iyw48ZuYIjRbOnFi2YQecNL0O3j5zQ3GGEv0s5QT6jeKec_&folder='
is evaluated as top.current_fullmail != 0 is true, so the main message
is shown instead of the frames, while in Firefox and other browsers
this statement is false.
In the main document's source
var current_fullmail=0;
so I have no idea what is happening there.
PS: The account is extended again.
I finally could make a small testcase. Load the readnavig.html in Konqueror to witness the bug. The bug is in line 6: <frame NAME="read_m" SRC="javascript:this.document.location.href='read_m.html'" MARGINHEIGHT="0" MARGINWIDTH="0"> Konqueror unconditionally loads the read_m.html as the main document instead of putting it in the frame. You can even see as the location entry changes. Andras Created an attachment (id=13357) framebug.tar.bz2 Further investigations indicates that the javascript is executed for the
current document, not for the frame itself.
In KHTMLPart::requestFrame there is the following code:
// Support for <frame src="javascript:string">
if ( url.find( QString::fromLatin1( "javascript:" ), 0, false ) == 0 )
{
QVariant res = executeScript( DOM::Node(frame->element()),
KURL::decode_string( url.right( url.length() - 11) ) );
KURL myurl;
myurl.setProtocol("javascript");
if ( res.type() == QVariant::String )
myurl.setPath(res.asString());
return processObjectRequest(*it, myurl, QString("text/html") );
}
executeScript() request the KJSProxy with KHTMLPart::jScript(). Here
d->m_frame->m_jscript is returned, altough I believe a new one should
be created, because I get the following debug output:
andris@stein:~/a> konqueror readnavig.html
khtml (jscript): Window::Window this=0x8479148 part=0x8409c00
frame=0x836f420 <--------- [the KJSProxy is created at the beginning]
khtml (jscript): Location::put href m_part=0x8409c00 <-------- [the same
part is used when changing the location![
khtml (jscript): Window::goURL dstUrl=file:///home/andris/a/read_m.html
I give up at this point due to the lack of knowledge in this area and
the lack of time.
An update: the bug is present in 3.5.1. :-( Is there somebody who can look at this or guide me a little how to fix it? This bug is the one which makes me install Firefox as a default browser for a library users (hundreds of visitors), instead of Konqueror. I'd suggest e-mailing kfm-devel. David is the person most likely to be able to help you with this. I actually started on this right now, it affects amazon.com as well (See bug #134791). I am just wondering whether you've done any testcasing on this --- the behavior of other browsers is quite bizarre and I am unable to come up with a good model for it. Haven't I attached a small example to reproduce it? If not, I will dig up and do it again (I'm not at home, but I might have the testcase on my laptop). And some time ago I tried Konqueror from KDE4 and I was amazed that there it worked. I did a quick diff, but couldn't find the change, well, as many things changed due to the Qt4 porting. Nothing relevant is changed there, that's weird. And I don't mean a testcase to reproduce --- I have that --- I meant more if you did any testing of details of behavior, but I guess not. Well, fair enough, not your responsibility anyway. All I did is what I summarized in the bug report. I will test again the KDE4 version once I'm home (2 days from now) to see if I'm really right that it is not broken there. SVN commit 590600 by orlovich:
Evaluate scripts in <iframe src=javascript:..> in the right context.
Affects amazon and freemail.hu
BUG:134791
BUG:106748
M +13 -6 khtml_part.cpp
--- branches/KDE/3.5/kdelibs/khtml/khtml_part.cpp #590599:590600
@@ -4314,12 +4314,19 @@
// Support for <frame src="javascript:string">
if ( url.find( QString::fromLatin1( "javascript:" ), 0, false ) == 0 )
{
- QVariant res = executeScript( DOM::Node(frame->element()), KURL::decode_string( url.right( url.length() - 11) ) );
- KURL myurl;
- myurl.setProtocol("javascript");
- if ( res.type() == QVariant::String )
- myurl.setPath(res.asString());
- return processObjectRequest(*it, myurl, QString("text/html") );
+ if ( processObjectRequest(*it, KURL("about:blank"), QString("text/html") ) ) {
+ KHTMLPart* p = static_cast<KHTMLPart*>(static_cast<KParts::ReadOnlyPart *>((*it)->m_part));
+
+ // See if we want to replace content with javascript: output..
+ QVariant res = p->executeScript( DOM::Node(), KURL::decode_string( url.right( url.length() - 11) ) );
+ if ( res.type() == QVariant::String ) {
+ p->begin();
+ p->write( res.asString() );
+ p->end();
+ }
+ return true;
+ }
+ return false;
}
KURL u = url.isEmpty() ? KURL() : completeURL( url );
return requestObject( *it, u );
This is amazing! I'm just updating my checkout to test, but it's good it's done before 3.5.5. It means that for many users here at the city library Konqueror will work just as good as Firefox (and even better in some cases). Could you please confirm it fully works, since there may be something else broken? Yes, I tested now and it works (there are some tabbed browsing issues, but that is not related to this bug). *** Bug 136224 has been marked as a duplicate of this bug. *** The problem isn't fully busted. After log in the main frame opens only in horizontally quarter size, but everything in place. If you enter to read the mails, now opens all correctly of it, exept one - the last arrived mail content frame not executes 'til I click one to show it. In content window frame the command icons are also not working, but if you click - opens another tab, with an unusable content on white page. Similar to if I want to answer to the mail, the answer frame opens correctly, but down the javascript buttons makes the same. #19 confirmed, so I reopen. The current working test account is: - "Nev" : "konqueroruser" - "Jelszo": "kubuntu" Bug still present (but use http://freemail.hu/fm/login1?ver=0 to get this version of the web page). I've tried to login from http://freemail.hu/fm/login1?ver=0 with konqueror 4.0.3. The page is rendered not so bad. The email list is ever on top and the mail content is on bottom. Scrolling it doesn't hide the email list. The problem here is that when you click on the Olvas link on the left, the email list will appear on the top, but the email content will not appear below, unless you click on an email. Instead it shows: read_m?sid=2qsbX7q27EkGx2H8PKBtG4d.mJEHymWDj69CwBlIKx7s3mzNQTaakmI9z3iMVhJKAfQhu2BuKWQJ1lSTXC7FcPg__&folder=new&msgnum=4&autoopen=0 Anyway, this (the "old freemail") interface is usable, but not known for regular users. The new one (http://freemail.hu) is the one that is completely unusable. I've see the "read_m?..." string too. Clicking on "olvas" should show even the first email content? The new interface is unusable. > ------- I've see the "read_m?..." string too. Clicking on "olvas" > should show even the first email content? Not exactly, a line: konqueroruser@freemail.hu Mappa: - nincs levél megnyitva (nincs levél megnyitva = there is no opened mail) SVN commit 794482 by orlovich: Let a redirect from within a javascript: frame source win out over the text.. (For src="javascript:this.window.location.href='foo'", on the old freemail.hu, better written as src="foo") CCBUG:106748 M +1 -1 khtml_part.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=794482 SVN commit 794484 by orlovich: automatically merged revision 794482: Let a redirect from within a javascript: frame source win out over the text.. (For src="javascript:this.window.location.href='foo'", on the old freemail.hu, better written as src="foo") CCBUG:106748 M +1 -1 khtml_part.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=794484 Let's mark it close, because it works in KDE4 trunk. |