W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

[Bug 15134] Please explain what the proper behavior of getSelection on a display:none iframe is

From: <bugzilla@jessica.w3.org>
Date: Tue, 10 Jan 2012 20:15:12 +0000
To: public-webapps@w3.org
Message-Id: <E1Rki6C-0005GP-Hr@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15134

Aryeh Gregor <ayg@aryeh.name> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #1 from Aryeh Gregor <ayg@aryeh.name> 2012-01-10 20:15:11 UTC ---
Sorry for the long time to respond -- I was on vacation for a while, then spent
a while doing other things.

The editing spec says "Every browsing context has a selection."
<http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections>  The HTML
spec says "When an iframe element is first inserted into a document, the user
agent must create a nested browsing context".
<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element>
 Thus the spec implies that any iframe in a document has a selection.  Testing,
this is how IE9, Chrome 17 dev, and Opera Next 12.00 alpha behave.  Firefox
12.0a1 returns null from getSelection() if the iframe is display: none.  I
don't see any advantage to Gecko's behavior, so I'll stick with the behavior of
the majority of browsers -- display: none should make no difference.

Reopen if you don't think the spec is clear enough.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 10 January 2012 20:15:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT