Closed
Bug 29794
Opened 25 years ago
Closed 25 years ago
Meta refresh tag isn't disabled in editor
Categories
(Core :: DOM: Editor, defect, P1)
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: michael, Assigned: akkzilla)
Details
(Whiteboard: Composer feature work)
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
Open a document in composer with this tag:
<meta http-equiv="refresh" content="3;URL=http://www.mozilla.org">
Say these magic words:
"one-one-thousand, two-one-thousand, three-one-thousand"
And now you are editing the Mozilla.org home page. The tag needs to be disabled.
|
||
Comment 1•25 years ago
|
||
reassign to akkana; akkana--can you look into this for M15 or M16?
Assignee: brade → akkana
Target Milestone: M15
|
Assignee | |
Comment 2•25 years ago
|
||
Will look at this in the M17 timeframe.
Target Milestone: M15 → M17
|
||
Comment 3•25 years ago
|
||
using the build from 6 APR, I cannot reproduce this on win95. The HTML I used in
the test file is this:
<html>
<head>
<title>test</title>
<meta http-equiv="refresh" content="3;URL=http://www.mozilla.org">
</head>
<body>
foobar
</body>
</html>
Michael -- can you reproduce this using a more recent version?
|
|
Assignee | |
Comment 4•25 years ago
|
||
I keep trying to un-UNCONFIRM this bug, and it keeps slipping away. Trying
again ... (I haven't actually reproduced it myself, though.)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
|
Reporter | |
Comment 5•25 years ago
|
||
Looks like the trick to reproducing the bug is having a doctype. Try adding:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Without this line, it doesn't refresh. With it, it does. Haven't tried any
other doctypes.
|
|
Assignee | |
Comment 7•25 years ago
|
||
I think the decision on this was that we wanted the original (referring) page to
appear in the editor, but we didn't want it to do the refresh. That's what old
composer seems to do, anyway. Adding a test case.
|
|
Assignee | |
Comment 8•25 years ago
|
||
|
|
||
Comment 9•25 years ago
|
||
updating keyword and status whiteboard to reflect that this is a beta 2 feature
work bug that the Composer team deems a must fix for beta 2.
Keywords: beta2
Whiteboard: Composer feature work
|
|
||
Updated•25 years ago
|
Priority: P3 → P1
|
|
Assignee | |
Comment 10•25 years ago
|
||
Travis says that this is a feature that nsDocShell::CancelRefreshURITimers()
should handle, but apparently it isn't working because the count of timers is
zero. I've added the call to CancelRefreshURITimers() to
nsEditorShell::OnStartDocumentLoad() (I also tried OnEndDocumentLoad(), but it
didn't help); Travis says he'll look at it to see why it's failing.
Assignee: akkana → travis
Status: ASSIGNED → NEW
|
||
Comment 11•25 years ago
|
||
I think there are a couple of problems here. First the OnStart is probably the
wrong place for this. The setting up of the refresh hasn't even occurred yet
here. Registering as a nsIWebProgressListener with the docshell and then
watching for onStatusChange flag_net_stop is probably the better place. Beyond
this, cancel fresh is being called on the wrong object. mDocShell in editor
world is the outer chrome docShell (I didn't write this). mContentAreaDocShell
is probably what you want to call this on. Flipping back to akkana.
Assignee: travis → akkana
|
|
Assignee | |
Comment 12•25 years ago
|
||
Thanks, Travis! Sure enough, that's the problem (it was the wrong docshell). I
have a fix ready to check in the next time the tree opens.
Status: NEW → ASSIGNED
OS: Windows NT → All
|
|
Assignee | |
Comment 13•25 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•