919297 - :target css pseudoclass inside iframe doesn't work properly

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[misuser8]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

I created following page: 

http://quatorze.atspace.co.uk/Webdev/shared/ffbug.html 

which contains iframe.

Page that loads inside iframe contains two divs named "DIV 1" and "DIV 2".

Each div can get targeted by clicking a link inside it and changes its appearance when targeted.

Iframe can get targeted by clicking link named "HIDE" on the main page, which refers to iframe.

When targeted, iframe's "display" property is set to "none" and it disappears.

In order to make it appear again I'm targeting other element (containing div) by clicking the link named "SHOW" which refers to containig div.

I take following steps:

1. I click the link inside "DIV 1". "DIV 1" gets targeted and changes its appearance according css rules specified.

2. I click the link on main page named "HIDE". Iframe disappears.

3. I click the link on main page named "SHOW". Iframe appears.

4. I click the link inside "DIV 2". "DIV 2" gets targeted and changes its appearance according css rules specified but "DIV 1" that is no longer targeted keeps same appearance as when it was targeted.


Actual results:

At step 4, div named "DIV 1" that is no longer targeted does not return to its initial appearance.


Expected results:

AT step 4 div named "DIV 1" should have returned to its initial appearance, that's what actually happens in Chrome.

Comment 1

[Giorgio]

Confirming the reproducibility of the bug, Win7 Firefox24

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

Attachment: ffbug2.html

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

Attachment: Reporter's Testcase

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

worked in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 ID:20110413222027 CSet: fca718600ca0

does not in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.12) Gecko/20100101 Firefox/10.0.12 ID:20130103094221 CSet: 9e1102e58ac8

Comment 5

[Alice0775 White]

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/5c6d107ede5a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110601 Firefox/7.0a1 ID:20110601030746
Bad:
http://hg.mozilla.org/mozilla-central/rev/840644b2b6a2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110601 Firefox/7.0a1 ID:20110601011530
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c6d107ede5a&tochange=840644b2b6a2


Regression window(cedar)
Good:
http://hg.mozilla.org/projects/cedar/rev/4a47b6944cb5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110531 Firefox/7.0a1 ID:20110531174638
Bad:
http://hg.mozilla.org/projects/cedar/rev/5ad2fcf8d9ed
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110531 Firefox/7.0a1 ID:20110531185514

Regressed by: Bug 598833

Comment 6

[Boris Zbarsky [:bzbarsky]]

[e-mail], thank you for the great testcase!

The bug here is that the ESM is what keeps track of the "thing that's currently matching :target" but the ESM is destroyed and recreated when we go through display:none.

We should either move the storage of the current :target to the document or not destroy the ESM on display:none or provide some mechanism for persisting part of the ESM state across display:none.

Olli, opinions?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

I think document itself should take care of :target.
We could store :target in document when ESM dies and get it back from there if a new ESM is created.

Comment 8

[misuser8]

This bug is still present in Firefox 28 !

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yes, because no one has had a chance to fix it yet....

Comment 10

[misuser8]

Here's another testcase that illustrates this bug:

http://quatorze.atspace.eu/Webdev/shared/ffbug/questions.html

Comment 11

[Dilraj Singh]

Hi! I would like to take a hack at this bug. This is my first time, so I am a bit confused, and sorry if this wasn't the right place to ask.

Comment 12

[Boris Zbarsky [:bzbarsky]]

No worries!  Please feel free to mail me with any questions, at least for the next week; after that I'll be on vacation for a bit.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

(In reply to Dilraj Singh from comment #11)
> Hi! I would like to take a hack at this bug. This is my first time, so I am
> a bit confused, and sorry if this wasn't the right place to ask.

This is definitely the right place to ask questions about how to tackle this bug. :)

Make sure to use the "Need more information" checkbox under the comment textarea if you have a question - you can target a "needinfo" at your mentor, who will have it added to their queue. That way, you never fall off the radar.

Comment 14

[Debojit Kaushik]

Hey. I would like to try my hand on this. I will start trying to solve this. Its running fine on chrome. but on mozilla its not. Let me check it out. If i solve it i will get back to u. :) this is my first try at open source collaborative programming. Hope i can do it. :D

Comment 15

[Debojit Kaushik]

Hey. I would like to try my hand on this. I will start trying to solve this. Its running fine on chrome. but on mozilla its not. Let me check it out. If i solve it i will get back to u. :) this is my first try at open source collaborative programming. Hope i can do it. :D

Comment 16

[Boris Zbarsky [:bzbarsky]]

Debojit Kaushik, welcome!  See comment 6 and comment 7 for what's going wrong here and how to start on fixing it.

Comment 17

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Firefox: 45.0.1, Build ID: 20160315153207
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Hi,

I have tested this issue on the latest Firefox (45.0.1) release, latest Nightly (48.0a1 - Build ID:20160320030409) build and I have managed to reproduce it. I have tested this using the provided test case and STR from comment 1. At step 4, when "DIV 2" should take focus, "DIV 1" does not change the color and keeps the focus.

Thanks,
Cosmin.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Yes.  That's obvious from comment 9...  I'm not sure why we were retesting this anyway, since it's obviously not fixed.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Unassigning, since it's pretty clear the current assignee is not working on this.

Comment 20

[Dilraj Singh]

Hi Boris, I had actually started working on it last week (re-familiarizing myself with the files involved in it). Sorry life had gotten in the way!

Should I try my hand on it for a couple days, and if I make progress, I can ask you to re-assign me?

Thanks

Comment 21

[Boris Zbarsky [:bzbarsky]]

Ah, if you're working on this again, back to you.  ;)  Sorry, just assumed based on the 2-year lag...

Comment 22

[Dilraj Singh]

yea, i incorrectly assumed that i could work on it slowly; so this time i am going to completely blitz it this week.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.