Closed Bug 625712 Opened 14 years ago Closed 14 years ago

docShell's useGlobalHistory=false doesn't work in ff4

Categories

(Core Graveyard :: History: Global, defect, P1)

defect

Tracking

(blocking2.0 final+)

RESOLVED FIXED
mozilla2.0b11
Tracking Status
blocking2.0 --- final+

People

(Reporter: szabo-a, Assigned: bzbarsky)

References

Details

(Keywords: regression, Whiteboard: [softblocker])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; hu-HU; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-3.1 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; hu-HU; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-3.1 Firefox/3.6.13

myBrowser.docShell.QueryInterface(Components.interfaces.nsIDocShellHistory).useGlobalHistory = false;

stopped working. It worked all right in 3.6 but doesn't stop using Global History in FF4 betas.




Reproducible: Always

Steps to Reproduce:
1. open a window from ff4 by an extension
2. define a browser with useGlobalHistory = false in the docShell
3. see FF's history.
Actual Results:  
FF 4 GlobalHistory  contains the unwanted URL's

Expected Results:  
stop pushing URL-s into global history.
Blocks: 556400
Keywords: regression
Confirming from newsgroup discussion and quick code perusal.
Status: UNCONFIRMED → NEW
Component: Bookmarks & History → Document Navigation
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: bookmarks → docshell
Hardware: x86_64 → All
Version: unspecified → Trunk
Indeed.  This is a regression from the IHistory changes.  Shawn, I think we need to fix this...  It breaks embedding cases and extension cases of various sorts.  Do you have time to take it, or should I?
blocking2.0: --- → ?
Component: Document Navigation → History: Global
QA Contact: docshell → history.global
(In reply to comment #2)
> Indeed.  This is a regression from the IHistory changes.  Shawn, I think we
> need to fix this...  It breaks embedding cases and extension cases of various
> sorts.  Do you have time to take it, or should I?
I won't have time until next week.
Shawn, have you had a chance to look at this yes. Can we figure out if it's a blocker or not so we can get it out of the nomination queue?
Estimating is hard.  I likely won't have time to look at this until bug 606966 is resolved.

bz - how bad does this break embedders?
It depends on the embeddor.  If nothing else, this looks like it could make embeddors privacy features not work right, no?

I guess I should just take this.  I do think this should block.  It's not hard to fix.
Assignee: nobody → bzbarsky
Priority: -- → P1
Alright, I can do the review then if that's OK with you (I'm not a peer, but you are the owner so...)
blocking2.0: ? → final+
Whiteboard: [softblocker]
Attachment #507025 - Flags: review?(sdwilsh)
Comment on attachment 507025 [details] [diff] [review]
Make useGlobalHistory work again on docshells.

r=sdwilsh

Should we care about a test here?
Attachment #507025 - Flags: review?(sdwilsh) → review+
> Should we care about a test here?

Probably, but I'd have to do some thinking to figure out how to write one...
Whiteboard: [softblocker] → [need landing][softblocker]
(In reply to comment #10)
> > Should we care about a test here?
> 
> Probably, but I'd have to do some thinking to figure out how to write one...

I can post my extension to you if it helps
No, I understand how to reproduce the problem in general.  I'm just not sure how to write an automated test for it.  "See history" doesn't work for an automated test... ;)
Pushed http://hg.mozilla.org/mozilla-central/rev/5e7903dbbd28
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [need landing][softblocker] → [softblocker]
Target Milestone: --- → mozilla2.0b11
(In reply to comment #12)
> No, I understand how to reproduce the problem in general.  I'm just not sure
> how to write an automated test for it.  "See history" doesn't work for an
> automated test... ;)

Write a reftest that contains a link to itself. Compare two copies of the reftest (different URLs linking to the same backend page?), one running in a <browser type="content" disablehistory="true"> and one running in a <browser type="content">. The latter's link will be visited ;-)
> The latter's link will be visited ;-)

Sadly, that won't work because there's no way to detect when the visited styling has been applied.
(In reply to comment #15)
> Sadly, that won't work because there's no way to detect when the visited
> styling has been applied.
You could write a chrome test that opens different xul windows with the right attributes and then tests if things are visited with nsIGlobalHistory2.
Depends on: 630145
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: