897194 - Markup from the wrong tab is showing up in the Inspector

Status: VERIFIED FIXED

(DevTools :: Inspector, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: 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.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

I should note that closing and reopening the Inspector doesn't fix it.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 3

[Dave Camp (:dcamp)]

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.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Is this a regression specific to 25?

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to [e-mail] [: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.

Comment 6

[Dave Camp (: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.

Comment 7

[Alex Keybl [:akeybl]]

(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?

Comment 8

[Dave Camp (:dcamp)]

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.

Comment 9

[Dave Camp (:dcamp)]

Jared, how's this working for you on nightly?

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

I just ran in to this again on the 9-19 UX Nightly build yesterday.

Comment 11

[Alex Keybl [:akeybl]]

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.

Comment 12

[Dave Camp (:dcamp)]

Attachment: v1

Comment 13

[Dave Camp (:dcamp)]

Attachment: windowid.patch

wrong patch

Comment 14

[Brian Grinstead [:bgrins]]

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.

Comment 15

[Dave Camp (:dcamp)]

https://hg.mozilla.org/integration/fx-team/rev/4082e7ff5e6e

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4082e7ff5e6e

Comment 17

[Dave Camp (:dcamp)]

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.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/2535acbe5c16
https://hg.mozilla.org/releases/mozilla-beta/rev/31f9299a4db2

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/31f9299a4db2

Comment 20

[Ioana (away)]

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.

Comment 21

[Ioana (away)]

Jared, given that QA can't reproduce this issue, can you please try to verify it on the fixed branches?

Comment 22

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 24

[u279076]

Updating status flag as per comment 22.