520729 - last loaded title attribute retained during private browsing

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[bugzilla.3.ado2102]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.2 NET_mmhpset (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.2 NET_mmhpset (.NET CLR 3.5.30729)

After exiting private browsing, the title attribute of the last image/link hovered on appears to be saved.  Make it pop up by holding down the middle mouse button and moving the cursor over the lower status bar (the one that says "done" when something is loaded).

Reproducible: Always

Steps to Reproduce:
CTRL+SHIFT+P (enter private browsing)

Browse website under private browsing.
Mouse over image or link with title attribute (pops up little yellow box with name)

CTRL+SHIFT+P (exit private browsing)

Press and hold middle mouse button.
Hover mouse over lower status bar (the one that says "done" when a page has finished loading)


Actual Results:  
Voila, the last loaded title attribute pops up as if you had just moused over the link again.

Expected Results:  
Deleted the title attribute from memory.

Comment 1

[Tracy Walker [:tracy]]

searches didn't find a dupe.

Comment 2

[(no longer active)]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100406 Minefield/3.7a4pre

I can confirm this.  This is probably the most weird bug I've seen in the private browsing module!  This might be something to fix in session restore code, though.  Investigating.

Comment 3

[(no longer active)]

Attachment: Patch (v1)

I think this would fix the problem.  I've posted the patch to the try server, and will verify the fix on Windows when it's finished.

I'm not sure if it's possible to test this automatically though.

Comment 4

[(no longer active)]

Comment on attachment 437415 [details] [diff] [review]
Patch (v1)

This doesn't solve the problem.  Still investigating.

Comment 5

[(no longer active)]

Attachment: Patch (v2)

OK, this patch actually solves the problem.  The same problem could be reproduced by getting a tooltip to show in one tab, then switching to another tab and performing the middle-mouse magic mentioned in comment 0.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 437427 [details] [diff] [review]
Patch (v2)

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>  * XXX - this must move into XBL binding/equiv! Do not want to pollute
>  *       browser.js with functionality that can be encapsulated into
>  *       browser widget. TEMPORARY!

TEMPORARY!, ha!

>- * NOTE: Any changes to this routine need to be mirrored in ChromeListener::FindTitleText()
>+ * NOTE: Any changes to this routine need to be mirrored in DefaultTooltipTextProvider::GetNodeText()

Good job on the CVS archeology :)

> function FillInHTMLTooltip(tipElement)
> {
>   var retVal = false;
>-  if (tipElement.namespaceURI == "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul")
>+  if (tipElement.namespaceURI == "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" ||
>+      !tipElement.ownerDocument)

Maybe add a comment here that explains what cases this is handling (tipElement is a document).

Comment 7

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/d0ccd8f2be49