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

RESOLVED FIXED in mozilla5

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Per Zimmerman, Assigned: mats)

Tracking

({regression, testcase})

Trunk
mozilla5
regression, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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
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
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
At a guess, we're now flushing frames at some point when things don't work happily for some reason....

Updated

7 years ago
Component: Graphics → Layout: Form Controls
OS: Windows 7 → All
See Also: → bug 642977

Comment 6

7 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?  ;-)
Well, that addition is what the guess was based on, yes.
(Assignee)

Comment 8

7 years ago
Created attachment 520365 [details]
nested nsTextEditorState::PrepareEditor

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

7 years ago
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?

Comment 10

7 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?
QA Contact: thebes → layout.form-controls
(Assignee)

Comment 11

7 years ago
Created attachment 520492 [details] [diff] [review]
fix v2, with reftest
Assignee: nobody → matspal
Attachment #520366 - Attachment is obsolete: true
Attachment #520492 - Flags: review?(ehsan)
(Assignee)

Updated

7 years ago
Flags: in-testsuite?
Keywords: testcase
Hardware: x86_64 → All
Version: unspecified → Trunk

Comment 12

7 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

7 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

7 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
http://hg.mozilla.org/mozilla-central/rev/974a47b48836
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla2.2
(Assignee)

Comment 16

7 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

7 years ago
Is anyone triaging approval2.0? flags?  did I use the wrong flag?
blocking2.0: --- → -
status2.0: --- → wanted
Attachment #520492 - Flags: approval2.0? → approval2.0-
You need to log in before you can comment on or make changes to this bug.