671055 - selection lost on text within iframe when overflow changes from auto to hidden?

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[Seth Spitzer]

selection lost on text within iframe when overflow changes from hidden to auto?

This might be pilot error and not a bug, but please see the attached test case.

Comment 1

[Seth Spitzer]

Attachment: test case

Comment 2

[Seth Spitzer]

correcting summary.

I'm using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a2) Gecko/20110704 Firefox/6.0a2

Comment 3

[Seth Spitzer]

this might be a dup of bug #490471

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

(In reply to comment #3)
> this might be a dup of bug #490471

Yeah. But here is a good testcase, that should be marked as dup of this.

Comment 6

[Seth Spitzer]

Nakano-san, thank you for the response.

Any suggestions on how to approach this bug?

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Looks like the selection is cleared actually at changing overflow (not repainting bug). For example, when you enable caret browsing mode, move caret into the iframe and change the overflow style by mouse hover, the caret is disappeared and you cannot expand selection by Shift+Arrow keys. This means the selection range was removed from the document or the document lost focus.

I'm not sure which component is the actual cause.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This looks like bug 619273 will fix it, to me.

Comment 9

[Seth Spitzer]

Thanks bz!  Cc'ing [e-mail] in case the test case in this bug helps him out.

Comment 10

[(no longer active)]

(In reply to comment #8)
> This looks like bug 619273 will fix it, to me.

Indeed, it will.  The root cause of this bug is that the flag about whether something is selected is stored on the frame, and it goes away when we reframe the element (for example, because of a style change).

Comment 11

[(no longer active)]

Hmm, this is not fixed yet.  Mats, do you know why?

Comment 12

[Mats Palmgren (inactive)]

Looks like we recreate the shell when reframing an <iframe>

#0  PresShell::Destroy
#1  DocumentViewerImpl::DestroyPresShell
#2  DocumentViewerImpl::Hide
#3  nsDocShell::SetVisibility
#4  nsFrameLoader::Hide
#5  nsSubDocumentFrame::HideViewer
#6  nsSubDocumentFrame::DestroyFrom
#7  nsIFrame::Destroy
#8  nsBlockFrame::DoRemoveFrame
#9  nsBlockFrame::RemoveFrame
#10 nsFrameManager::RemoveFrame
#11 nsCSSFrameConstructor::ContentRemoved
#12 nsCSSFrameConstructor::RecreateFramesForContent
...

Comment 13

[Jaroslav Benc]

Attachment: Same if display:none is set on one of iframe's parent.

A simple scenario - iframe based editor shown in a tab set where switching between tabs is implemented as display:none/block

Comment 14

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.