Closed Bug 287446 Opened 19 years ago Closed 19 years ago

[FIXr]default value on input not shown in an iframe if the iframe is position: relative


(Core :: Layout: Form Controls, defect, P2)






(Reporter: xonium, Assigned: bzbarsky)




(Keywords: testcase)


(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.6) Gecko/20050226 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

This page: has an iframe. In the iframe there is an
input box with a value="buggybuggy".

This means the default text should be buggybuggy in that input box, but it's not.

No other things in the iframe have any affect on that what i think but!

The page that has the iframe has some things that makes the value="buggybuggy"
not visible.

The bugg.js and bugg.css that is linked to the document.

Bugg.js has some parts from the well known styleswitcher.js that many people use
to switch stylesheets. You can see it here

I removed all parts that seemed to not have anything to do with the bug.

bugg.css has the simple:

#id {
	position: relative;

It also works if i has it as a class with .id instead. Note! The <link> tag used
to import the css file needs a title.

The last part is that the iframe is inside the div tag with the id="id". The bug
doesn't work if i just has the css style in the html document like
style="position: relative;" and the div tag has no class or id.

I have also tested with different names on that style and the bug was stil there.

And i have tested to use a span instead of a div and the bug was still there, so
i assume it will be there in a p tag or anything else.

ONE more thing. Also check out this: The bug is not
there!! The only difference is on this the iframe src is On the iframe
src is Both pages buggiframe.html is
identical! So if you find no other explanation for this it is weird, it seems
like if the page is on another server the bug happens, if it's on the same
server it doesn't? Ok i haven't tested on other servers yet but i will.

Reproducible: Always

Steps to Reproduce:

Expected Results:  
I should be able to see the value. I see it it internet explorer for example. ok
i know IE always corrects wrong code and makes it look good anyway, but is it
anything wrong here?
Also no text in input field with todays trunk build.
Assignee: firefox → nobody
Component: General → Layout: HTML Frames
Product: Firefox → Core
QA Contact: general → layout.html-frames
Version: unspecified → Trunk
Attached file testcase
The testcase requires that the page in the iframe be loaded remotely.
Severity: major → normal
Component: Layout: HTML Frames → Layout: Form Controls
Ever confirmed: true
Keywords: testcase
QA Contact: layout.html-frames → layout.form-controls
Summary: default value on input not shown in an iframe if the page with the iframe contains certain things → default value on input not shown in an iframe if the iframe is position: relative
Some more testcases, with float: left, float: right, position: absolute  -  the
input box values isn't shown either.
This is basically the same as bug 287120
Depends on: 287120
Or perhaps not...

The real problem with this testcase is that the main page is on one server and
the iframe is on a different one.  Which means they have different security

When we kill off the subframe's presshell (because style changes cause a layout
frame reconstruct in the parent document), the text control tries to stash its
current value in its DOM node.  The code to stash away the value serializes the
editor's contents into a string, and then sets the value to that string. 
Serializing creates a DOM range on the relevant nodes in the editor and
serializes the range.

The problem is that creation of the range uses the DOM range methods.  In this
case that means that we do security checks in them.  The subject principal is
the JS that caused the style change (in the parent document).  The object
principal is that of the anonymous nodes in the child (so the principal of the
child document).  The principals don't match, so we get a security exception
(which editor ignores).

So I see the following options:

1)  The text control frame should escalate its privileges in some cases before
    calling into the editor.
2)  The editor should in some cases use non-DOM apis which don't do security
    checks to init its ranges.

We've had issues with this before (see bug 219848 comment 24) but at the time it
really _was_ JS accessing the data, just JS with expanded privileges.  Now we
just need the data for our internal use....
Attached patch Proposed fixSplinter Review
Assignee: nobody → bzbarsky
Attachment #180732 - Flags: superreview?(jst)
Attachment #180732 - Flags: review?(jst)
No longer depends on: 287120
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Summary: default value on input not shown in an iframe if the iframe is position: relative → [FIX]default value on input not shown in an iframe if the iframe is position: relative
Target Milestone: --- → mozilla1.8beta2
Comment on attachment 180732 [details] [diff] [review]
Proposed fix

- In nsTextControlFrame::SetValue():

+      // Time to mess with our security context... See comments in GetValue()
+      // for why this is needed.  Note that we have to do this up here,
+      // otherwise SelectAll() will fail.
+      nsCOMPtr<nsIJSContextStack> stack =
+	 do_GetService(";1");
+      PRBool pushed = stack && NS_SUCCEEDED(stack->Push(nsnull));
+      nsCOMPtr<nsISelection> domSel;
+      nsCOMPtr<nsISelectionPrivate> selPriv;
+      mSelCon->GetSelection(nsISelectionController::SELECTION_NORMAL,
+      if (domSel)
+      {
+	 selPriv = do_QueryInterface(domSel);
+	 if (selPriv)
+	   selPriv->StartBatchChanges();
+      }
       nsCOMPtr<nsIPlaintextEditor> htmlEditor = do_QueryInterface(mEditor);
       if (!htmlEditor) return;

Early return after we've pushed a null JS context onto the stack. That's not
good. Either move code around here, or pop if we return early here.

r+sr=jst with that fixed.
Attachment #180732 - Flags: superreview?(jst)
Attachment #180732 - Flags: superreview+
Attachment #180732 - Flags: review?(jst)
Attachment #180732 - Flags: review+
Attached patch With that fixedSplinter Review
Requesting 1.8b2 approval.  This patch makes us properly save and restore form
state in subframes that come from a different host.  It should be reasonably
safe, I think....
Attachment #181837 - Flags: approval1.8b2?
Summary: [FIX]default value on input not shown in an iframe if the iframe is position: relative → [FIXr]default value on input not shown in an iframe if the iframe is position: relative
Comment on attachment 181837 [details] [diff] [review]
With that fixed

Attachment #181837 - Flags: approval1.8b2? → approval1.8b2+
Closed: 19 years ago
Resolution: --- → FIXED
Verified. Simon, the fix will be in 1.1.
Blocks: 321494
No longer blocks: 321494
Depends on: 321494
Flags: in-testsuite?
Added a test for this as part of bug 477700.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.