This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15134 - Please explain what the proper behavior of getSelection on a display:none iframe is
Summary: Please explain what the proper behavior of getSelection on a display:none ifr...
Status: RESOLVED WORKSFORME
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-09 23:46 UTC by Eric Seidel
Modified: 2012-01-10 20:15 UTC (History)
2 users (show)

See Also:


Attachments

Description Eric Seidel 2011-12-09 23:46:03 UTC
Please explain what the proper behavior of getSelection on a display:none iframe is

See:
https://bugzilla.mozilla.org/show_bug.cgi?id=585229
https://bugs.webkit.org/show_bug.cgi?id=43655
Comment 1 Aryeh Gregor 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.