WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
14933
Quick Reply feature misplaces iframe on KFAN fourms
https://bugs.webkit.org/show_bug.cgi?id=14933
Summary
Quick Reply feature misplaces iframe on KFAN fourms
Dan
Reported
2007-08-10 15:24:44 PDT
When trying to reply on the KFAN.com forums, the "fast reply" option does not work. I click on it, and the page just reloads rather than a reply box popping up.
Attachments
Add attachment
proposed patch, testcase, etc.
David Kilzer (:ddkilzer)
Comment 1
2007-08-11 07:13:05 PDT
Forum test account created (See
Bug 5695 Comment #14
): Email:
webkit-test@hotmail.com
User: webkit Pass: w3bk1t
David Kilzer (:ddkilzer)
Comment 2
2007-08-11 08:20:07 PDT
Confirmed with a local debug build of WebKit
r25008
with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218). I see two issues with this page: 1. Clicking on the Quick Reply link for a given post appears to reload the entire page and places an <iframe> at the top of the page instead of placing it where the user has scrolled to. This happens whether we're using the default Safari user agent or spoofing as Firefox 2.0.0.2 (using the Debug menu in Safari), so I'm inclined to think that this may be a WebKit bug. Note that this forum is based on Community Server 2.0 (
http://communityserver.org/
), so if turns out not to be a WebKit bug, it will probably be an evangelism issue for that software. 2. Once the Quick Reply <iframe> is drawn (at the top of the page), a plain textarea is used instead of a rich text editor. This is because the FreeTextBox editor doesn't support WebKit/Safari. I filed
Bug 14943
to track that issue. This bug should track the issue described in Item 1.
David Kilzer (:ddkilzer)
Comment 3
2007-08-11 08:22:05 PDT
(In reply to
comment #2
)
> 1. Clicking on the Quick Reply link for a given post appears to reload the > entire page and places an <iframe> at the top of the page instead of placing it > where the user has scrolled to. This happens whether we're using the default > Safari user agent or spoofing as Firefox 2.0.0.2 (using the Debug menu in > Safari), so I'm inclined to think that this may be a WebKit bug.
In (the real) Firefox 2.0.0.6, the entire page does NOT appear to reload, and the <iframe> is placed within the visible area of the page where the user happens to be. This is the expected behavior.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug