1145010 - In responsive design mode, navigating back from a #target doesn't remove ":target"-dependent styles

Status: VERIFIED FIXED

(DevTools :: Responsive Design Mode, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

(NOTE: I ran into this when playing around with existing reftest fragmentIdentifier-rect-01.svg. I'm including a tweaked testcase that more directly reproduces this bug.)


STR (also written inside the testcase):
 0. Load testcase.
 1. Enter responsive design mode (ctrl+shift+M)
 2. Click the link ("here") in the testcase to navigate to #redView.
    (Or just manually add "#redView" to the URL bar and hit enter)
 3. Navigate back, with back button or alt+leftarrow.

EXPECTED RESULTS: The document should end up lime.

ACTUAL RESULTS: The document stays red.

This is a regression; I see this in current Nightly, but not in Firefox release (version 36). I also only hit this in responsive design mode, for some reason.

(It's also conceivable that this can be triggered in HTML, as well. I tried to work up a testcase in HTML, but it didn't work, perhaps due to a typo on my part or perhaps due to :target working differently there.)

Comment 1

[Daniel Holbert [:dholbert]]

Slightly-narrowed regression range:
I get EXPECTED RESULTS in current beta (version 37); ACTUAL RESULTS in Firefox developer edition (version 38).

Comment 2

[Daniel Holbert [:dholbert]]

Mozilla-central regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=540077a30866&tochange=34e2d2bd7ec4

mozilla-inbound regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d98309db7e20&tochange=bd7d13e5875c

I don't see anything SVG or document-navigation-related in the (smaller) inbound range, but I do see this:
> ae9cc9b5f5dd	Paul Rouget — Bug 1067145 - Make responsive design e10s-ready. r=ochameau

That seems like the most-likely culprit.

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

This appears to only affect Windows and Linux from what I can tell.

I can confirm the issue on Windows, but on Mac it does not seem to appear.

Comment 6

[iighite]

I am assuming my issue is supposed to be filed here... So I'm using the latest firefox developers edition (40.0a2) and for several versions (39) there seems to be a regression with CSS target... specifically targeting the target. My snippet of code below works in every browser including latest stable version of firefox (37.0.2) but not in the developers edition.

#site-search {
	position: absolute;
        height: 5.5em;
	padding:0.625em;
	border-bottom:0.063em solid #fff;
	background: #EEEEEE;
}

#site-search:not(:target) {
	z-index:1;
	height:0;
	padding:0;
	border:none;
}

In the developers edition when I select the link to the target it has the height properties stated in the css and all but when I select another target link the #site-search div should have no height and no padding and no border.

Comment 7

[Robert Longson [:longsonr]]

(In reply to iighite from comment #6)

I think you have something different. Please raise your own new bug to track it.

Comment 8

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to iighite from comment #6)
> I am assuming my issue is supposed to be filed here... So I'm using the
> latest firefox developers edition (40.0a2) and for several versions (39)
> there seems to be a regression with CSS target... specifically targeting the
> target. My snippet of code below works in every browser including latest
> stable version of firefox (37.0.2) but not in the developers edition.
> 
> #site-search {
> 	position: absolute;
>         height: 5.5em;
> 	padding:0.625em;
> 	border-bottom:0.063em solid #fff;
> 	background: #EEEEEE;
> }
> 
> #site-search:not(:target) {
> 	z-index:1;
> 	height:0;
> 	padding:0;
> 	border:none;
> }
> 
> In the developers edition when I select the link to the target it has the
> height properties stated in the css and all but when I select another target
> link the #site-search div should have no height and no padding and no border.

If this happens *when Responsive Mode is open*, then it's this bug.  If not, then please file a new one.  It could be a related problem, but it's not precisely the same as this one.

Comment 9

[iighite]

(In reply to Robert Longson from comment #7)
> (In reply to iighite from comment #6)
> 
> I think you have something different. Please raise your own new bug to track
> it.

actually I just checked and it only happens in responsive mode. so maybe it's the same bug. :) Sorry if I caused any confusion or inconvenience.

Comment 10

[iighite]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #8)
> (In reply to iighite from comment #6)
> > I am assuming my issue is supposed to be filed here... So I'm using the
> > latest firefox developers edition (40.0a2) and for several versions (39)
> > there seems to be a regression with CSS target... specifically targeting the
> > target. My snippet of code below works in every browser including latest
> > stable version of firefox (37.0.2) but not in the developers edition.
> > 
> > #site-search {
> > 	position: absolute;
> >         height: 5.5em;
> > 	padding:0.625em;
> > 	border-bottom:0.063em solid #fff;
> > 	background: #EEEEEE;
> > }
> > 
> > #site-search:not(:target) {
> > 	z-index:1;
> > 	height:0;
> > 	padding:0;
> > 	border:none;
> > }
> > 
> > In the developers edition when I select the link to the target it has the
> > height properties stated in the css and all but when I select another target
> > link the #site-search div should have no height and no padding and no border.
> 
> If this happens *when Responsive Mode is open*, then it's this bug.  If not,
> then please file a new one.  It could be a related problem, but it's not
> precisely the same as this one.

yes it only happens in *when Responsive Mode is open*

Comment 11

[Robert Longson [:longsonr]]

Then it is *this* bug so you don't need a new one.

Comment 12

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

The patch up for review in bug 1189702 also fixes this bug.

Comment 13

[Sunny]

I have reproduced this bug on windows 7 64 bit in Nightly 41.0a1 (2015-05-21).

The Bug's Fixed Verified on latest nightly 43.0a1 (2015-08-21).

Build Id   : 20150821030204
User Agent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0

Comment 14

[Nazir Ahmed Sabbir [:NaSb]]

Successfully reproduce this bug on Nightly 39.0a1 (2015-03-18) (Build ID: 20150318030202) with the instruction from comment 0 on Linux x64

This Bug is now verified as fixed on Latest Firefox Nightly 43.0a1 (2015-09-05) (Build ID: 20150905030205), 
Latest Developer Edition 42.0a2 (2015-09-05) (Build ID: 20150905004017) and
Latest Beta 41.0b7 (Build ID: 20150903133607)


Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0

As it is also verified on Windows (Comment 13), Marking it as verified!