[FIX]Assertion after EnableGlobalHistory

RESOLVED FIXED in mozilla1.9alpha1

Status

Core Graveyard
Embedding: GRE Core
P3
minor
RESOLVED FIXED
12 years ago
2 years ago

People

(Reporter: Mikhail Zabaluev, Assigned: bz)

Tracking

({assertion})

Trunk
mozilla1.9alpha1
assertion

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: 

I embed the Gecko engine built from Xulrunner trunk. On creation of a browser window, it fails an assertion in nsWebBrowser::Create after EnableGlobalHistory has failed. Continued execution after the assertion exhibits no problems, and my embedding application doesn't even intend to use history. I opt to disable it both via nsIWebBrowserSetup and the flag to nsIWebNavigation::LoadURI.

Reproducible: Always




Xulrunner built from trunk as of 2006-04-18.
Created attachment 219199 [details] [diff] [review]
This should fix it

Benjamin, does this need sr?
Assignee: nobody → bzbarsky
Status: UNCONFIRMED → ASSIGNED
Attachment #219199 - Flags: review?(benjamin)
OS: Windows XP → All
Priority: -- → P3
Hardware: PC → All
Summary: Assertion after EnableGlobalHistory → [FIX]Assertion after EnableGlobalHistory
Target Milestone: --- → mozilla1.9alpha

Updated

12 years ago
Attachment #219199 - Flags: review?(benjamin) → review+
Attachment #219199 - Flags: superreview?(darin)
(Reporter)

Comment 2

12 years ago
The patch solves my problem, thank you.

Comment 3

12 years ago
Comment on attachment 219199 [details] [diff] [review]
This should fix it

Hmm... it might be nice to set mHistoryEnabled inside EnableGlobalHistory.  That way, mHistoryEnabled does not get out-of-sync if someone happens to call EnableGlobalHistory without manually updating mHistoryEnabled.

Also, does it make sense to set mHistoryEnabled to true if EnableGlobalHistory fails?

sr=darin
Attachment #219199 - Flags: superreview?(darin) → superreview+
mHistoryEnabled is just an indicator of what the setup boolean is.  I could rename it to mShouldSetUpHistoryOnCreate if that would help...

> Also, does it make sense to set mHistoryEnabled to true if EnableGlobalHistory
> fails?

Yes, since it doesn't indicate whether history is actually enabled but whether we _should_ enable it on create.
Created attachment 220361 [details] [diff] [review]
Updated to darin's comments
Attachment #219199 - Attachment is obsolete: true
Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.