Open Bug 919297 Opened 6 years ago Updated 10 months ago

:target css pseudoclass inside iframe doesn't work properly

Categories

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

defect
Not set

Tracking

()

People

(Reporter: misuser8, Assigned: dilrajsingh.7, Mentored)

References

(Depends on 1 open bug)

Details

(Keywords: regression, testcase, Whiteboard: [lang=c++][tw-dom])

Attachments

(2 files)

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.
Confirming the reproducibility of the bug, Win7 Firefox24
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
Component: Untriaged → Layout
OS: Windows XP → All
Product: Firefox → Core
Hardware: x86 → All
Version: 23 Branch → Trunk
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
misuser8@aol.com, 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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bugs)
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.
Flags: needinfo?(bugs)
This bug is still present in Firefox 28 !
Yes, because no one has had a chance to fix it yet....
Whiteboard: [mentor=bzbarsky@mit.edu][lang=c++]
Here's another testcase that illustrates this bug:

http://quatorze.atspace.eu/Webdev/shared/ffbug/questions.html
Mentor: bzbarsky
Whiteboard: [mentor=bzbarsky@mit.edu][lang=c++] → [lang=c++]
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.
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.
Assignee: nobody → dilrajsingh.7
(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.
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
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
Debojit Kaushik, welcome!  See comment 6 and comment 7 for what's going wrong here and how to start on fixing it.
Flags: needinfo?(bzbarsky)
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.
Yes.  That's obvious from comment 9...  I'm not sure why we were retesting this anyway, since it's obviously not fixed.
Unassigning, since it's pretty clear the current assignee is not working on this.
Whiteboard: [lang=c++] → [lang=c++][tw-dom]
Assignee: dilrajsingh.7 → nobody
Component: Layout → DOM
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
Ah, if you're working on this again, back to you.  ;)  Sorry, just assumed based on the 2-year lag...
Assignee: nobody → dilrajsingh.7
yea, i incorrectly assumed that i could work on it slowly; so this time i am going to completely blitz it this week.
Depends on: 1265068
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.