Closed Bug 897194 Opened 7 years ago Closed 7 years ago
Markup from the wrong tab is showing up in the Inspector
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?
(In reply to email@example.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.
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.
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+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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.
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.
Jared, given that QA can't reproduce this issue, can you please try to verify it on the fixed branches?
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
You need to log in before you can comment on or make changes to this bug.