11008 - (ClearAll) Single easily-accessible button to clear cache, etc.

Status: VERIFIED DUPLICATE of bug 416233

(SeaMonkey :: Preferences, enhancement, P3)

Description

[hecker]

(Forwarded from a customer) "I see a great need to be able to flush
the cache (memory and disk) without going through the extensive process of
navigating the 'edit/preferences/advanced/cache' route.  I would suggest a
button in the tool bar to flush the caches with a single click of the mouse.
This addition should apply to all versions/OS."

I (Frank Hecker) believe that any such "clear all" button should also
invoke related functions such as clearing cached passwords used in HTTP
authentication, cached passwords for POP and IMAP, and so on; if a crypto module
is present then the button should also invoke the function(s) required to log
out of the module (and thus the module would require reentering the module's
passphrase or PIN at next use).  As an advanced feature, the button could notify
XPCOM-connected components that maintain data or password caches and have
requested such notification so that they can clear their own caches.  In essence
the button would be an easily-accessible single place for a user to "log out" of
Mozilla (e.g., prior to walking away from their system for a temporary break)
and not leave any cached data or passwords around for others to view or
retrieve.

Comment 1

[Gagan]

Good idea. Deferred till cache works in Necko.

Comment 2

[Matthew Tuck [:CodeMachine]]

So the interface would allow registering an action that gets called?  Maybe they
should also register the name of that action, so that this button could bring up
a dialog with a list of all the clearances (all initially checked) and you can
choose which you desire.

Do anyone think the dialog is a good idea, or is it better to just clear them
all?

Comment 3

[djarrell]

From a security standpoint, I would prefere to see a <B>"one touch"</B> to clear
everything.

Comment 4

[Matthew Tuck [:CodeMachine]]

How so?  You're not denying anyone anything by making it two touch.  If the
options were described well it should be obvious to novices what the
ramifications of each are.

What I really want to know is if there's any benefit to being able to choose
some but not all.  The answer is possibly no, in which case the issue goes away.

Comment 5

[Gagan]

Deferring past cache landing. CC'ng fur.

Comment 6

[Matthew Tuck [:CodeMachine]]

This could be extended past security issues to include privacy issues, ie
clearing history, URL location bar, autocomplete list, last thing in the find
box, etc.

I don't know whether you'd want to include these in the same button/issue.

Comment 7

[leger]

Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache
component.

Comment 8

[Gagan]

updating cc list.

Comment 9

[davidm]

*** Bug 17403 has been marked as a duplicate of this bug. ***

Comment 10

[davidm]

There should be an option to do all this clearing automatically when the app is 

quit. I don't think this belongs as a toolbar button, but a pref panel to 

control what is cleared ( cache, history, location bar, ... ), and a button 

there and maybe a menu item sounds reasonable. I think this is really an XPApps 

bug in that it should just be UI work to call the various components.

Comment 11

[Warren Harris]

Moving to M17 which is now considered part of beta2.

Comment 12

[Paul MacQuiddy]

qa to tever

Comment 13

[Gagan]

I agree with davidm, off to don...

Comment 14

[leger]

Putting on [nsbeta2-] radar.  

Comment 15

[don]

Move to M20 target milestone.

Comment 16

[verah (gone)]

Nav triage team: There's a button in the prefs to do this. Good idea to make it 
more accessible, but not high priority. Reassigning to ben.

Comment 17

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 18

[Jacob Steenhagen]

My recomendation would be a menu item.  Toolbar buttons take up too much space.
 This menu could also be an expandable one

Clear Cache >  Everything
               Allow me to Choose
               --------------------
             X Clear Cache on Exit

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

I don't believe this type of thing should appear in the main browser UI (at
least, not until I see statistics to show it being a common scenario for most
users ;). However it would work nicely as an optional drop-in component for
those that wanted it, or a keybinding of some sort. Reassigning to
[e-mail] and marking HELP WANTED to attract attention.

Comment 20

[David Krause]

BenG, helpwanted as a keyword is the correct way to attract attention.

Comment 21

[Zecho]

Why not add one button to the toolbar, which can be user configured to activate
any menu button - url - feature they deisre?

Comment 22

[HJ]

Why are the buttons so big? Just make them smaller, and you will have more space
to use for this cleaning the cache for example. Some site's now need to clean
the cache befor loading the loaded pages again! You need to clean the cache time
after time before the page pops up! So it's a major need!

See bug 62394 and bug 62767

Friendly, HJ.

Comment 23

[Jesse Ruderman]

See also bug 38521, "Preferences Toolbar, for most commonly used prefs".

This bug currently covers two things that seem different to me: adding an 
optional toolbar button (or menu item) to clear the cache immediately, and 
adding a "clear cache on exit" pref.  I think bug 17403 should be reopened for 
the pref.

HJ: the toolbar buttons are large to make them easier to click on when your 
cursor starts halfway across the screen.

Comment 24

[Cormac F]

*** Bug 100459 has been marked as a duplicate of this bug. ***

Comment 25

[Dimitrios]

*** Bug 115583 has been marked as a duplicate of this bug. ***

Comment 26

[Neil Pryde]

Attachment: Screenshot of quick-pref menubutton in MultiZilla v1.1.08F

Can't we use something like this?

Comment 27

[Neil Pryde]

Attachment: Screenshot of QuickPref button in mozilla 2001-12-24-03 on WinNT4

This time that same pref menu can be used from the default mozilla toolbar.

Comment 28

[Matthew Kruer]

This option should also be enable for the Quick Launch so you can flush the
cache without even having to open the browser. Also an option to flush the cache
every time you fully close out (Not including the Quick Launch) should be included.

Comment 29

[Paul Harrison]

I get the horrible feeling I'm treading on toes by writing this but what the heck...

We got impatient at my office waiting for this, so we implemented our own. Such
is the joy of Mozilla having a UI written in XML and JavaScript. Doing the
following will change the Mozilla UI so that clicking on 'Reload' with the CTRL
key held down will, instead of reloading anything, clear the caches instead.

1. Locate the chrome/comm.jar file whereever you installed Mozilla.
2. Unzip it (taking care to keep directories)
3. cd to content/navigator
4. Load navigator.js into your favourate editor. Add the following to the end:


function prefClearCache(aType)
{
    var classID = Components.classes["@mozilla.org/network/cache-service;1"];
    var cacheService = classID.getService(Components.interfaces.nsICacheService);
    cacheService.evictEntries(aType);
}

function prefClearAllCache()
{
    prefClearCache(Components.interfaces.nsICache.STORE_IN_MEMORY);
    prefClearCache(Components.interfaces.nsICache.STORE_ON_DISK);
    alert('Caches cleared');
}

[If Mozilla wants to copy this hack [Good Ghod man, why?!] you'll presumably
need to internationalise the alert statement. If indeed you want to keep it at all.]

Save the results.

5. Load navigator.xul into your favourate editor. Find the line:

oncommand="if (event.shiftKey) BrowserReloadSkipCache(); else BrowserReload();"  

Change it to:

oncommand="if (event.shiftKey) BrowserReloadSkipCache(); else { if
(event.ctrlKey) prefClearAllCache(); else BrowserReload(); }"

Save it.

6. Rezip comm.jar, taking care to ensure that the directories all are saved and
start at the 'content' level (as in blah.js in navigator in content should be
"content/navigator/blah.js")

7. Replace (after backing up the old one) comm.jar in your Mozilla directory's
chrome subdirectory.


This works under Mozilla 0.9.8 under WinNT 4 and Win98, and we assume other
platforms (there's nothing radical here.)

I don't expect anyone wants to copy this [Ctrl+Reload? Ew! And as for using an
unlocalized alert()...], but FWIW I waive my copyrights over the above hack.

Comment 30

[Matt Bookman]

I agree with what Jesse Ruderman posted.  There are two different issues here.

The first issue is the one that I am interested in - it is an outstanding
feature of other browsers, Netscape 4 and Internet Explorer included, that when
you exit the browser, the cache gets "invalidated".  It then makes it very easy
to generically say to users of your web application that under certain
circumstances, they should just restart the browser and various caching
issues/problems will go away.

Having a toolbar button to clear the cache might be nice, but it doesn't seem to
me like something new needs to be invented here.  I think that we should do what
people have been doing ever since they first started using the web - close the
browser and the cache will be cleared/invalidated.

Comment 31

[Paul Harrison]

I'm not happy with the suggestion that clearing the caches should be done by
closing the browser. I don't want to lose the pages I have up every time I want
to check a page.

I'm a developer who's currently working on web apps. In order to see changes to
code, I have to clear the cache. Typically, this is done several times an hour,
during the usual cycle of "Change, test, change again, test...". The cache has
to be cleared, because a Reload isn't quite what I want - you end up with zany
behaviour if you're using frames with Javascript [no, no bug in Mozilla, there's
a limit to what Mozilla can do], for instance. Closing the browser might be a
"solution" of sorts but it means losing the rest of the state of the browser. I
don't want that! I can see it'd be even worse if, say, my app used session
cookies or anything like that.

The problem at the moment is that clearing the cache is more of the pain than it
ought to be. Menu->Edit->Preferences->Advanced->Cache->Clear Memory Cache; then
clear Disk Cache, Ok, Close. That's a lot of mouse clicks for something that I'm
constantly having to do.  And there's that whole thing about Memory and Disk
Cache - why the devil would I care about clearing one and not the other? I'm not
psychic, I don't know where Mozilla is caching my pages, and I'm not going to
about:cache every time I want to find out.

Actually, perhaps that's another option. Rather than making the change a part of
the GUI, perhaps it could be added to the about:Cache page. That way developers
only need keep that page open in a tab or window, and have complete control over
the contents of the cache; meanwhile, the user interface stays as simple as it
should be. How does that sound?

Comment 32

[Matt Bookman]

In retrospect, I completely agree that it is not appropriate for the cache to 
be invalidated when one exits the browser.  What I noticed is that Netscape 4 
and Internet Explorer behave this way only when "once per session" is the cache 
setting.  When Mozilla is set to "once per session", then it too fundamentally 
invalidates the cache when you exit.  It just turns out that every IE and 
Netscape 4 browser I had checked had this as the cache setting.

With regards to the other point of the bug, adding an easier way to clear the 
cache to the UI, I could still get behind that, because clearing the cache is 
often very handy in practice and it is currently a pain to get to.

Comment 33

[Andrew Hagen]

*** Bug 119512 has been marked as a duplicate of this bug. ***

Comment 34

[Wesha]

*** Bug 159794 has been marked as a duplicate of this bug. ***

Comment 35

[Alex Bishop]

*** Bug 168220 has been marked as a duplicate of this bug. ***

Comment 36

[Michael Lefevre]

*** Bug 170660 has been marked as a duplicate of this bug. ***

Comment 37

[Thomas Alabor]

try this: http://www.xulplanet.com/downloads/prefbar/ - an additional PrefBar -
the thing I was looking for...

Comment 38

[nucleos]

In my opinion, Mozilla should really have this function. I took Mozilla for the
tab system, but to go to Edit > Preferences (...) make me lose lot of time...
When I enter things like "php", I've got now a BIG list of sites, and I want
juste two or three. So it happens frequently I want to delete the cache, the
cookies, and the history ! And those things are very long to do...

Comment 39

[Jo Hermans]

*** Bug 217419 has been marked as a duplicate of this bug. ***

Comment 40

[Jo Hermans]

*** Bug 229917 has been marked as a duplicate of this bug. ***

Comment 41

[Asa Dotzler [:asa]]

*** Bug 184272 has been marked as a duplicate of this bug. ***

Comment 42

[benc]

This is really well-done in Firebird, althought the button lives inside Prefs
UI, and not on the front end UI. 

Since this bug has been open for a long time, can anyone give an updated appeal
for 1.7 -> 1.8, why would we still need it in trunk?

(also, removed blocks on bug 17403)

Comment 43

[Bugzilla]

Working great (tested on 1.8a2 build 2004070807 on Windows XP)

I'll try to make a browser extension (XPI) to easily implement this as well as
"Clear History" and "Clear Location bar" (probably by using the Alt key)

Comment 44

[Marc Croteau]

Attachment: Screen Capture of new "Clear Cache" preference

Comment 45

[Marc Croteau]

Attachment: Screen capture of new "Clear History" preference

Comment 46

[Marc Croteau]

Attachment: Files modified to add this new feature

Additions and Modifications in all enclosed files are preceeded by my name and
date, except for all.js where changes appear at the end of the file.

Comment 47

[Marc Croteau]

Hello all,

I now have a fully working solution for this bug. It took me one day of digging
in the Mozilla code to understand how things worked, but I finally got this
fixed. I will not release it as an extension (see my previous message #43) as I
found it was easier to simply include these small changes in the core code.

My solution adds the following new features (see attached screen captures):

1. Add a checkbox in Prefs - Advanced - Cache to "Clear cache at shutdown"
2. Add 2 checkboxes in Prefs - History to "Clear History" and "Clear Location
Bar History" at shutdown
3. Adds 2 new behaviours to the "Reload" button:
   - Pressing <Ctrl><Reload> will clear cache immediately
   - Pressing <Alt><Reload> will clear History and Location Bar immediately

I include the modified code as part of this posting since I don't know how to
get it in Thinderbox or CVS. The code is based on 1.8a2 (2004071408) and
includes comments with my name and date for all the items I modified in the
original code.

I am willing to accept assignment for this bug but I'll need some help on the
way things need to be done to get it properly approved and included in the
public code.

Comment 48

[Marc Croteau]

Attachment: ZIPped Patches

Comment 49

[Frédéric Buclin]

Your screenshots look very nice. I LOVE them! I will try your patch as soon as
possible.

Comment 50

[Marc Croteau]

Attachment: Screen capture of cache on Linux

Comment 51

[Marc Croteau]

Attachment: Screen capture of History on Linux

Comment 52

[Marc Croteau]

I just added screen captures of my patch running on Mozilla 1.7 for Linux.

I also noticed that I included "pref-cache.js" but I made no modifications to
this file.

Comment 53

[Marc Croteau]

Attachment: ZIPped Patches

Added Installation Instructions in the ZIP comment and removed one file.

Comment 54

[Brodie]

Marc: please attach your patches as a patch file and not as a zip.

Comment 55

[Marc Croteau]

(In reply to comment #54)
> Marc: please attach your patches as a patch file and not as a zip.

How can I create a patch file ?

Comment 56

[Marc Croteau]

(In reply to comment #54)
> Marc: please attach your patches as a patch file and not as a zip.

How can I create a patch file ?

Comment 57

[Brodie]

1. download the Mozilla source code as a tar archive and extract
2. ensure that you have the latest versions of the files you are editing by:
     cvs co file.ext
3. edit the files to make your changes
4. make a diff by:
     cvs diff -u8pN file.ext

Don't change lines that aren't necessary to be changed. Maintain the current 
coding style, etc. See http://www.mozilla.org/hacking/life-cycle.html

Gerv's patchmaker makes it easy to create patches which span multiple files 
(like yours). See http://www.gerv.net/software/patch-maker/
You would install it, then create a new patch and add all of the files to it. 
Creating a single patch file which combines the changes from all modified files 
is then easy. e.g.

(from the top of the mozilla source tree)

pms singlebutton
  (this creates a new patch called "singlebutton")
pma defaults\pref\all.js
pma chrome\comm\content\communicator\pref\pref-cache.xul
pma chrome\comm\content\communicator\pref\pref-history.xul
pma chrome\comm\content\navigator\navigator.js
pma chrome\comm\content\navigator\navigator.xul
  (this adds these files to the patch, best to do from the top
   of the source tree for consistency and to show exactly where
   all of the files are)
pmd 
  (generate a patch file called "singlebutton.diff")
pmv
  (view the patch file in your editor)

You then attach that patch file to the bug.

Comment 58

[Marc Croteau]

(In reply to comment #57)
Thanks,

I'll try these instructions and produce a patch.

Comment 59

[Marc Croteau]

Attachment: Patch to resolve this bug

(In reply to comment #58)
> (In reply to comment #57)

Done.

I added the patch.diff file to this bug

Comment 60

[Brodie]

You will need to fix the corruption of the Japanese font name 
("font.name.serif.ja") in all.js. Ensure that the editor that you are using is 
fully unicode enabled. If you don't know and you are using Win 2000/XP then use 
notepad to edit the file as it will not corrupt the file.

I don't like the way you are overloading the Reload button. I doubt that you 
will get that past UI review. My suggestions to get this passed would be to 
just add the prefs and keybindings and worry about the UI later. UI is far 
harder to get agreement on.

Best way to find people to review your patch is to look at the log for the 
files you are modifying and see who has been reviewing patches on that file 
recently. neil%parkwaycc.co.uk might be able to help you. I can't - I'm not 
around for a month or more and don't know xul/js anyhow.

Be patient - you'll get review/super in time. To ask for review from someone, 
edit the patch attachment and set the ? flag for review and supply a name for 
the reviewer. 

Comment 61

[jag (Peter Annema)]

As Brodie said, I don't like overloading the reload button like that. We could
add a menu item for this. I don't think we need to or should put this more
visibly in the UI. If anything, we could maybe put another icon/button in the
status bar next to the lock, cookie information and online/offline toggle.

I do like those additions you've made to the prefs though. Especially if they
can be locked (I forget if we get that for free by default or need to add code
for it), it'll be very useful for kiosks and libraries.

Comment 62

[[e-mail]]

Note that the patch cannot be used as-is because it actually performs its
actions when any browser window (such as a pop-up window) is closed. Actually
intercepting profile shutdown would need a new component, as I doubt that any
existing component is suitable for modification.

Oh, and I don't like overloading the reload modifiers either.

Comment 63

[Frédéric Buclin]

(In reply to comment #62)
> Note that the patch cannot be used as-is because it actually performs its
> actions when any browser window (such as a pop-up window) is closed. Actually
> intercepting profile shutdown would need a new component, as I doubt that any
> existing component is suitable for modification.

Why not deleting cache and/or history on shutdown, using
quit-application-requested ? No need to introduce a "new component".

Comment 64

[[e-mail]]

(In reply to comment #63)
>Why not deleting cache and/or history on shutdown, using
>quit-application-requested ? No need to introduce a "new component".
Well, profile-before-change would actually be the correct event to observe, but
only components will still be around and able to observe that event.

Comment 65

[Marc Croteau]

(In reply to comment #64)
> (In reply to comment #63)
> >Why not deleting cache and/or history on shutdown, using
> >quit-application-requested ? No need to introduce a "new component".
> Well, profile-before-change would actually be the correct event to observe, but
> only components will still be around and able to observe that event.
> 

Thanks for your comments.

I'm currently on vacation and hope to be able to deal with all of them after
mid-august. Keep supplying comments and tips (like that profile-based quit).

As I said earlier, this is my first patch for Mozilla and I don't yet know all
the workarounds and code tricks.

Comment 66

[Marc Croteau]

(In reply to comment #64)
> (In reply to comment #63)
> >Why not deleting cache and/or history on shutdown, using
> >quit-application-requested ? No need to introduce a "new component".
> Well, profile-before-change would actually be the correct event to observe, but
> only components will still be around and able to observe that event.
> 
I did a search on "quit-application-requested" and "profile-before-change" in
the CVS tree and did not find occurences of these strings in Javascript files;
only in cpp files.

I tried my patch in different areas (profileSelection.js, globalOverlay.js) but
was not successful. I am now stuck as I don't know where to include this code to
make it work *only" when the *last* navigator window closes.

Since I don't have a cpp compiler and am not too familiar with cpp, I'd prefer a
solution where I could modify js file(s). I am now exploring the use of observer
on one of those events but would appreciate pointers on how to use obervers.

Any ideas ?

Comment 67

[[e-mail]]

(In reply to comment #66)
>I am now stuck as I don't know where to include this code to
>make it work *only" when the *last* navigator window closes.
It needs to go in your components subfolder (I don't know where in the Mozilla
source tree it would belong). See offlineStartup.js for example.

Comment 68

[Marc Croteau]

Attachment: Patch to empty cache when window is closed

This is an cleaned up version of my previous patch:
- No more <Ctrl> and <Alt> features on the reload button
- Used a different text editor to get rid of the "all.js" problem I had in the
previous patch

This patch *still* empties cache when *any* window is closed (using the [X]
button). I keep it here because it is still an "interesting" solution.

Comment 69

[Marc Croteau]

Attachment: Patch to empty cache when exiting the navigator

This patch is based on the same code used to empty cache when window is closed.
The main difference with this patch is that is clears cache *only* when the
user properly exits the browser (using File - Exit). Clicking on the "Close
Window" button [X] with this patch (on any open window) does *not* empty
caches.

Comment 70

[Marc Croteau]

I was finally able to find a way to clear cache when exiting the browser. I
could not find a way to use "profile-before-change" so I used something close to
"quit-application-requested".

Feel free to test and comment on the latest patch.

Comment 71

[Frédéric Buclin]

I'm not sure deleting the cache everytime a window is closed is a good solution.
Imagine everytime you have a popup on your screen!!!

But deleting the cache on exit only (instead of each profile change, see comment
64) seems a good compromise for me. I think this could be enough.

Marc, have you already tried your patch? Does it work fine?

Comment 72

[[e-mail]]

Well, I don't think implementing the backend in JavaScript is the way to go.
For instance, the history service already knows about the profile-before-change
notification, so all it needs to do is to clear itself if the pref is set.

Comment 73

[Frédéric Buclin]

neil, could you suggest some patch? You have more experience than Marc or me.
And we could then expect this bug to be closed, 5 years after it was opened.

Comment 74

[Marc Croteau]

(In reply to comment #73)
> neil, could you suggest some patch? You have more experience than Marc or me.
> And we could then expect this bug to be closed, 5 years after it was opened.

I second that.

I really tried my best to have something that works and both patches DO work.
But I am not skilled enough to implement anything other than JavaScript.

As far as I'm concerned, this contribution is all I could do. I cannot go further.

I reassign this bug to Neil in the hope that he can solve this issue

Comment 75

[Fabian Rodriguez:MagicFab]

I haven't read the entire comments but thought this extension already did what's
being requested here:

http://extensionroom.mozdev.org/clav/#x
http://extensionroom.mozdev.org/more-info/xkiosk

Unfortunately the files don't seem to be available there anymore. There's also
another one, that let you program several click events, which could be used as a
workaround, but I can't seem to find it.

Comment 76

[Marc Croteau]

(In reply to comment #69)

For those who are interested in this patch but don't want to diff and all, I put
"installable" (exe and zip) versions on my Web site.

I am starting with the current Mozilla releases (1.8a4 and 1.7.3) in en-US and
fr-FR. I will keep these patches up to date as new versions come out and until
this fix makes it to the official Mozilla code.

Link here: http://marc.bugzilla/11008-ClearCache/
Instructions: http://marc.bugzilla/11008-ClearCache/readme.html

Comment 77

[Marc Croteau]

(In reply to comment #76)

Sorry, wrong URLs. Here are the right ones:

Link here: http://marc.bugzilla.free.fr/11008-ClearCache/
Instructions: http://marc.bugzilla.free.fr/11008-ClearCache/readme.html

Comment 78

[Marc Croteau]

Since I no longer use the Mozilla Suite (following abandonned development from
the Mozilla team), I moved to Firefox.

I worked on a patch for Firefox, but with the new features in Firefox 1.1 (this
feature is now included), it is no longer necessary that I continue this
development.

Therefore, I will not continue to maintain this patch.

Comment 79

[benc]

Jag: I think this is WONTFIX.

Comment 80

[Ian Tommins ('thelem')]

I agree, and since no one has commented otherwise in the last 2.5 years -> WONTFIX

Comment 81

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #80)
> I agree, and since no one has commented otherwise in the last 2.5 years ->
> WONTFIX

Don't do that again.  There are very few people who can make that decision.

Reopening.

Comment 82

[Andrei Boros]

To me it seems like Mozilla Suite was abandoned, and dev moved to SeaMonkey... 

Shouldn't this follow the same path? 

"Clear cache on exit" checkbox seems a good idea. 

A button to clear the cache on toolbar, or somewhere easier to access the in the prefs, maybe, but then this button should zero each file in cache, including cache index, before actually deleting the files. 

Comment 83

[Matthew T (active 1999-2002)]

Firefox 2's "Clear Private Data" does this quite handily (though the dialog is a bit confusing). Anyone still developing Seamonkey could copy FF's code.

Comment 84

[Tony Mechelynck [:tonymec]]

Anyone still working on this? Latest comment by the assignee seems to be comment #61 dated 2004-08-12 (more than 3½ years ago). Latest comment of any kind is more than a year old. Notwithstanding comment #81, shouldn't this bug be closed WONTFIX?

Comment 85

[Robert Kaiser]

I implemented this in bug 416233 (port of the FF code), didn't see the bug here when I filed the other one, but now it's a dupe.

Comment 86

[benc]

Robert,

Thanks.

Comment 87

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d3d1b9beddb6
[components] Issue https://github.com/mozilla-mobile/android-components/issues/11008 - Make HistoryMetadataKey parcelable