Closed Bug 1234423 Opened 9 years ago Closed 3 years ago

contenteditable="true" on div breaks meta refresh

Categories

(Core :: DOM: Editor, defect, P5)

43 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 844401

People

(Reporter: nick.lothian, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20151216175450 Steps to reproduce: In the following page the meta refresh tag fails to work. Removing or changing to contenteditable="false" makes it work as expected <!doctype html> <head> <title>Index</title> <!-- Redirect user to survey site after 18 mintues !--> <meta http-equiv="refresh" content="5;url=http://example.com" /> </head> <body > <div contenteditable="true" > Test content </div> </body> </html> Actual results: Nothing. Expected results: Redirect to example.com
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Firefox → Core
I am not sure if this is the right component for this bug, but if someone thinks that is not the right place for this bug to land, please change it. Thank you.
Component: Untriaged → Editor

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5

Seems also dup. of bug 844401.
Reading https://bugzilla.mozilla.org/show_bug.cgi?id=844401#c1, is this behavior intended?

Flags: needinfo?(masayuki)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #4)

Seems also dup. of bug 844401.

Right.

Reading https://bugzilla.mozilla.org/show_bug.cgi?id=844401#c1, is this behavior intended?

Not sure, but from user's point of view, it may be reasonable because it can avoid data-loss.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(masayuki)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.