Closed Bug 29794 Opened 20 years ago Closed 20 years ago

Meta refresh tag isn't disabled in editor

Categories

(Core :: DOM: Editor, defect, P1, critical)

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: michael, Assigned: akkzilla)

Details

(Whiteboard: Composer feature work)

Attachments

(1 file)

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.
reassign to akkana; akkana--can you look into this for M15 or M16?
Assignee: brade → akkana
Target Milestone: M15
Will look at this in the M17 timeframe.
Target Milestone: M15 → M17
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?
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
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.

I should have placed this in m16
Target Milestone: M17 → M16
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.
Attached file Test case
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
Priority: P3 → P1
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
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
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
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Keywords: nsbeta2
verified in 4/25 build.
Status: RESOLVED → VERIFIED
Keywords: beta2
You need to log in before you can comment on or make changes to this bug.