Closed
Bug 642800
Opened 14 years ago
Closed 14 years ago
Textarea within floated or overflow hidden div in iframe don't display content and can't get focus when containing iframe is resized by script
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla5
People
(Reporter: per.zimmerman, Assigned: MatsPalmgren_bugz)
References
()
Details
(Keywords: regression, testcase)
Attachments
(4 files, 1 obsolete file)
|
644 bytes,
text/html
|
Details | |
|
603 bytes,
text/html
|
Details | |
|
11.02 KB,
text/plain
|
Details | |
|
3.45 KB,
patch
|
ehsan.akhgari
:
review+
dveditz
:
approval2.0-
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.133 Safari/534.16
Build Identifier: 20110303194838
Text in textarea within div with overflow: hidden or float:left disappears depending on window size. The container page has an iframe which is resized when the window is resized. iThe iframe content page include style rules with media query "@media only screen and (max-width: 480px)". The iframe is 500px wide and should not have those CSS rules applied for width less than 480px. When iframe.style.height is set the textarea goes blank at some heights for the iframe.
Reproducible: Always
Steps to Reproduce:
1. Open the example page http://www.dentaku.com/demo/firefox4rc/iframe-resize/
2. Resize the window slowly
3. The text content in the textareas is hidden or shown depending on window size
Or
1. Create "iframe.html":
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Iframe</title>
<style type="text/css">
body {
background: red;
}
</style>
<script type="text/javascript">
function resize(e) {
var node = document.getElementById("iframe");
node.style.display = "none";
node.style.height = Math.max((document.documentElement.clientHeight - 12), 0) + "px";
node.style.display = "block";
}
// Add load event
window.addEventListener("load", resize, false);
window.addEventListener("resize", resize, false);
</script>
</head>
<body>
<iframe src="IFrameContent.htm" id="iframe" frameborder="0" style="width: 500px"></iframe>
</body>
</html>
2. Create "IFrameContent.htm":
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title></title>
<style>
body {
background: #ccc;
}
@media only screen and (max-width: 480px) {
.overflow-hidden
{
overflow: hidden;
}
.float-left
{
float: left;
background: #f0f;
}
}
</style>
</head>
<body>
<h1>Iframe content</h1>
<div class="float-left">
<textarea>This text should be visible when window is resized </textarea>
</div>
<div class="overflow-hidden">
<textarea>This text should be visible when window is resized </textarea>
</div>
</body>
</html>
3. Open "index.html" in FF 4 RC
4. Resize the window slowly
5. The text content in the textareas is hidden or shown depending on window size
Actual Results:
Text in textarea disappears from depending on window size. When they are blank, it's not possible to set focus in textarea.
Expected Results:
Text in textareas should be visible at all time
|
||
Comment 1•14 years ago
|
||
|
|
||
Comment 2•14 years ago
|
||
|
|
||
Comment 3•14 years ago
|
||
Looks like this regressed in this range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=54184cfa6f0e&tochange=9f412256da4c
Bisecting now.
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → Graphics
Ever confirmed: true
QA Contact: layout.form-controls → thebes
|
|
||
Comment 4•14 years ago
|
||
Hg bisect says:
The first bad revision is:
changeset: 60477:b6384e736df2
user: Mats Palmgren <matspal@gmail.com>
date: Fri Jan 14 01:22:26 2011 +0100
summary: Bug 602331 - selection addRange cannot select nodes that are being dynamically appended to the DOM. r=roc a=blocking2.0:final
Keywords: regression
|
|
||
Comment 5•14 years ago
|
||
At a guess, we're now flushing frames at some point when things don't work happily for some reason....
|
|
||
Updated•14 years ago
|
|
||
Comment 6•14 years ago
|
||
(In reply to comment #5)
> At a guess, we're now flushing frames at some point when things don't work
> happily for some reason....
Could that be the flush added in that patch? ;-)
|
|
||
Comment 7•14 years ago
|
||
Well, that addition is what the guess was based on, yes.
|
Assignee | |
Comment 8•14 years ago
|
||
The flush leads to a nested nsTextEditorState::PrepareEditor which
protects against that (added in bug 577518).
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsTextEditorState.cpp#1161
|
|
Assignee | |
Comment 9•14 years ago
|
||
It's the script runner at the end that restores the selection state
that causes it. Would it be safe to allow that part to nest?
|
|
||
Comment 10•14 years ago
|
||
(In reply to comment #9)
> Created attachment 520366 [details] [diff] [review]
> wip1 (wdiff)
>
> It's the script runner at the end that restores the selection state
> that causes it. Would it be safe to allow that part to nest?
No. Is the problem solved by adding a script blocker inside RestoreSelectionState::Run before calling AddRange?
|
||
Updated•14 years ago
|
QA Contact: thebes → layout.form-controls
|
|
Assignee | |
Comment 11•14 years ago
|
||
Assignee: nobody → matspal
Attachment #520366 -
Attachment is obsolete: true
Attachment #520492 -
Flags: review?(ehsan)
|
|
Assignee | |
Updated•14 years ago
|
|
|
||
Comment 12•14 years ago
|
||
Comment on attachment 520492 [details] [diff] [review]
fix v2, with reftest
The code change looks good, but please add a comment on why the script blocker is necessary.
I don't think you need the spellcheck="false" in the test, though. Please remove it.
Attachment #520492 -
Flags: review?(ehsan) → review+
|
|
||
Comment 13•14 years ago
|
||
Also, it would be great if you could move the reftest to layout/reftests/editor, which would make it easier for me to run this reftest on editor changes (since it's really about the editor).
|
|
Assignee | |
Comment 14•14 years ago
|
||
Added a code comment, removed the @spellcheck, and moved the tests to
layout/reftests/editor
FTR, that spellcheck=false thing is to avoid misspelled word underlines
which used to be added asynchronously (at least on some platforms) which
could cause oranges in reftests. I'll just have to spell correctly for
tests to pass now I guess... :-)
Fixed in Cedar:
http://hg.mozilla.org/projects/cedar/rev/974a47b48836
Flags: in-testsuite? → in-testsuite+
Whiteboard: fixed-in-cedar
|
||
Comment 15•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla2.2
|
|
Assignee | |
Comment 16•14 years ago
|
||
Comment on attachment 520492 [details] [diff] [review]
fix v2, with reftest
Low-risk regression fix for mozilla-2.0 branch.
Attachment #520492 -
Flags: approval2.0?
|
|
Assignee | |
Comment 17•14 years ago
|
||
Is anyone triaging approval2.0? flags? did I use the wrong flag?
|
|
||
Comment 18•14 years ago
|
||
Christian?
|
||
Updated•14 years ago
|
|
|
||
Updated•14 years ago
|
Attachment #520492 -
Flags: approval2.0? → approval2.0-
You need to log in
before you can comment on or make changes to this bug.
Description
•