Markup from the wrong tab is showing up in the Inspector

VERIFIED FIXED in Firefox 26

Status

defect
VERIFIED FIXED
6 years ago
Last year

People

(Reporter: jaws, Assigned: dcamp)

Tracking

(Blocks 1 bug)

Trunk
Firefox 28
x86_64
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(firefox24 wontfix, firefox25+ wontfix, firefox26+ fixed, firefox27 fixed, firefox28 verified, firefox-esr24 wontfix, b2g-v1.2 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Posted image 2013-07-23_1556.png
Just came across this in Firefox Nightly UX (7-22-2013). See the attached screenshot.

In the screenshot you'll see that the breadcrumbs are correctly pointing to the selected image, but the markup view shows what appears to be markup from the Zimbra email client, not my blog.

Unfortunately I'm not sure how this happened. I checked and I don't have the Inspector running on my Zimbra webpage. 

I'm filing this in the hopes that I will come across some STR later or maybe other people will be running in to this bug.
I should note that closing and reopening the Inspector doesn't fix it.
Better STR is to have a separate window opened. It appears to use the selected tab from the other window. Closing the second window also exits the developer tools from the first window.
Rather than the "currently selected tab" thing we do now, we should just include the windowID and compare those directly.  I have a patch to do that, I can get it ready for inclusion next week.
Is this a regression specific to 25?
Flags: needinfo?(jaws)
(In reply to lsblakk@mozilla.com [:lsblakk] from comment #4)
> Is this a regression specific to 25?

I believe so. I think it has to do with the new remote inspector, but dcamp will know more than I.
Flags: needinfo?(jaws) → needinfo?(dcamp)
This existed before 25, but exacerbated a bit in 25.  The debugger might have seen this problem before, now the inspector can.

The fix for this should be pretty simple.
Flags: needinfo?(dcamp)
Assignee: nobody → dcamp
Status: NEW → ASSIGNED
(In reply to Dave Camp (:dcamp) from comment #6)
> This existed before 25, but exacerbated a bit in 25.  The debugger might
> have seen this problem before, now the inspector can.
> 
> The fix for this should be pretty simple.

Any updates?
Yeah - I think my guess as to the problem was wrong, and I think the right fix to this bug is a combination of the patches in bug 888492 and bug 909121.  Will be nominating 909121 for uplift once it lands, and I'll go nominate 888492 now.
Jared, how's this working for you on nightly?
I just ran in to this again on the 9-19 UX Nightly build yesterday.
bug 909121 landed on m-c on 9/15, and bug 888492 on 8/28. Sounds like this isn't resolved in that case.

Time's running out if you still want to get this fix into FF25.
Flags: needinfo?(dcamp)
Posted patch v1 (obsolete) — Splinter Review
Attachment #821269 - Flags: review?(rcampbell)
Attachment #821269 - Flags: feedback?(bgrinstead)
Flags: needinfo?(dcamp)
Attachment #821269 - Flags: review?(rcampbell)
Attachment #821269 - Flags: review?(bgrinstead)
Attachment #821269 - Flags: feedback?(bgrinstead)
wrong patch
Attachment #821269 - Attachment is obsolete: true
Attachment #821269 - Flags: review?(bgrinstead)
Attachment #821276 - Flags: review?(bgrinstead)
Blocks: 927630
Comment on attachment 821276 [details] [diff] [review]
windowid.patch

Review of attachment 821276 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.  I have checked switching between both multiple windows and multiple tabs, and have this fixes devtools opening on the wrong page, and also prevents the browser from hanging during a fast switch.

::: toolkit/devtools/server/actors/webbrowser.js
@@ +582,5 @@
>                 "grip() shouldn't be called on exited browser actor.");
>      dbg_assert(this.actorID,
>                 "tab should have an actorID.");
>  
> +    let windowUtils = this.window

You may consider making this.windowUtils a getter on the BrowserTabActor prototype, as it is used in 3 places and it is a little wordy.  r+ either way, though.
Attachment #821276 - Flags: review?(bgrinstead) → review+
https://hg.mozilla.org/mozilla-central/rev/4082e7ff5e6e
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 28
Comment on attachment 821276 [details] [diff] [review]
windowid.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): exacerbated by remote inspector
User impact if declined: broken devtools, hangs
Testing completed (on m-c, etc.): been on m-c for a few days
Risk to taking this patch (and alternatives if risky): not very risky
String or IDL/UUID changes made by this patch: none.
Attachment #821276 - Flags: approval-mozilla-beta?
Attachment #821276 - Flags: approval-mozilla-aurora?
Attachment #821276 - Flags: approval-mozilla-beta?
Attachment #821276 - Flags: approval-mozilla-beta+
Attachment #821276 - Flags: approval-mozilla-aurora?
Attachment #821276 - Flags: approval-mozilla-aurora+
Keywords: verifyme
I tried to reproduce this issue several times with Firefox 25 on a Windows 7 64bit machine with no success.

From what I see in this report, this bug is (highly?) intermittent. Unless there are any guidelines to ensure it reproduces in a few tries, we won't be able to verify it.
Keywords: verifyme
Keywords: verifyme
Jared, given that QA can't reproduce this issue, can you please try to verify it on the fixed branches?
Flags: needinfo?(jaws)
I can't reproduce this right now. I'll reopen if I stumble across it in the future, but I'm happy with calling this verified.
Status: RESOLVED → VERIFIED
Flags: needinfo?(jaws)
Keywords: verifyme
Updating status flag as per comment 22.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.