element inspector context switch link in style declaration goes to wrong declaration in styles pane

RESOLVED FIXED in Firefox 44

Status

()

Firefox
Developer Tools: Inspector
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: schavery, Assigned: tromey)

Tracking

31 Branch
Firefox 44
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140715214327

Steps to reproduce:

Inspect an element that has a inline style declaration somewhere in the page. Click the link to the style declaration.


Actual results:

I am taken to an inline style declaration, but not the one containing the selector I was interested in. It may be the case that it always takes me to the first inline style declaration, but I can't confirm this.


Expected results:

I should be taken to the set of rules containing the selector inquestion, and to the line where that selector begins.

I also have problems with named stylesheets (external files) not going to the correct line of declaration.
Component: Untriaged → Developer Tools: Inspector

Comment 1

3 years ago
Can you provide an example page on which you see this, perhaps as an attachment to the bug or as a public link?
Flags: needinfo?(schavery)

Comment 2

3 years ago
how can I "inspect an element"?
(Reporter)

Comment 3

3 years ago
@mxpaco: By element inspector, I mean the window that opens when you select the "Inspect Element (Q)" option from the context menu. There is a tab titled 'Inspector'. You can see a textual representation of the document here, and when you select one of those elements, the style declarations relevant to that element are listed.

I have created a webpage with a very simple proof of concept. In testing, I have determined that chromium 37 also displays this behavior.
http://stevenavery.com/mozilla/
Flags: needinfo?(schavery)

Comment 4

2 years ago
can´t reproduce the bug

Comment 5

2 years ago
This was fixed in https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3edc8d4a1e198314f5d7ebd2967b85842beef602&tochange=d1c5a7c5b4331ee9ea5443de893fcfd0a5b80e2a

and narrowed down to fx-team, mozregression gives:

 9:49.29 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=f354f556b59136bc052e5b2c57d7d28e7242de37&tochange=40f709d9c088dfc4ba1b55fb80920b5ff5102842

 9:50.32 LOG: MainThread main INFO Looks like the following bug has the changes which introduced the fix:
https://bugzilla.mozilla.org/show_bug.cgi?id=984880

Which makes sense, and means this got fixed in 44.
Assignee: nobody → ttromey
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Depends on: 984880
OS: Linux → All
Hardware: x86_64 → All
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
You need to log in before you can comment on or make changes to this bug.