453459 - Bug pages no longer added to bfcache due to unload listener on Window

Status: VERIFIED FIXED

(Bugzilla :: Bugzilla-General, defect, P2)

Description

[Boris Zbarsky [:bzbarsky]]

After the 3.2 upgrade, none of the bugzilla pages are added to bfcache, as far as I can see.

STEPS TO REPRODUCE:
1)  Load https://bugzilla.mozilla.org/show_bug.cgi?id=452731
2)  Load https://bugzilla.mozilla.org/show_bug.cgi?id=344559
3)  Click the "Back" button in your browser

EXPECTED RESULTS: speedy back

ACTUAL RESULTS: slow back

NOTES:  This is particularly bad when trying to go back to the page you get right after commenting, since that one requires a repost to actually show... which is undesirable.

ADDITIONAL INFORMATION:  The issue seems to be that there is an unload listener attached to the Window (presumably by one of the copious scripts that the bug page is including).  Any time that happens, we have to turn off bfcache.

I have to say I have a hard time believing we need an unload listener here.

In any case, this is making using Bugzilla pretty miserable, especially when following dependency chains.

Comment 1

[Dave Miller [:justdave]]

I'm unable to duplicate this problem in Gran Paradiso 3.0.3pre.  After adding mkanat and pyrzak to the CC and submitting, I clicked on bug 452731 in the dependency list, visited that bug, then hit the Back button, and got back here without having to reload (I see the list of addresses it emailed to at the top and everything).

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK, that could be just the HTTP cache being nicer to you than to me.  Try this:

1)  Load this bug page.
2)  Run

      javascript:document.documentElement.textContent='OK'; void(0)

    from the URL bar.
3)  Load google.com.
4)  Hit back.

You should see the OK, not the bug page.

Comment 3

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080902011844 SeaMonkey/2.0a1pre

After following the steps in comment #2:
At step 3, http://www.google.com/ auto-resends me to http://www.google.be/ (my IP address is 87.65.220.145 aka 145.220-65-87.adsl-dyn.isp.belgacom.be)
At step 4, I get back to the bug page, not to google.com and not to "OK".

If I click Forward before Commit, I'm back to Google.
Then Back brings me back to Bugzilla (after several seconds of the tab icon "throbbing"), and my partially-filled textarea (i.e., what I had already typed of this comment) is still there.

Then if I click the drop-down icon at the right end of my Location bar, "http://www.google.com/" is at top and "javascript:document.documentElement.textContent='OK'; void(0)" is second from top (both of them without double quotes of course).

I'm not sure if I have reproduced the bug. Boris, change the OS to All if I did.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> You should see the OK, not the bug page.

I thought this part was pretty clear.  This bug is XP, of course, since it's a bug in the JS in bugzilla...

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I also saw this issue several times within the last days. I already talked with Justdave on IRC but wasn't able to find reproducible STR. The pages are added to the bfcache but under some circumstances it doesn't work. Mostly I noticed that directly after I logged in. Opening other bugs in their own tab hasn't shown this issue.

Comment 6

[Boris Zbarsky [:bzbarsky]]

In case it helps, here's the JS stack to the point where the window.addEventListener("onunload", ...) call happens:

(gdb) jsstack 
0 [native frame]
1 anonymous(K = undefined, L = [function], N = "unload", M = [object Window @ 0xd15f220 (native @ 0xd15e34c)]) ["https://bugzilla.mozilla.org/js/yui/yahoo-dom-event.js":9]
    this = [object Object]
2 anonymous() ["https://bugzilla.mozilla.org/js/yui/yahoo-dom-event.js":11]
    n = undefined
    EU = [object Object]
    this = [object Window @ 0xd15f220 (native @ 0xd15e34c)]
3 <TOP LEVEL> ["https://bugzilla.mozilla.org/js/yui/yahoo-dom-event.js":9]
    this = [object Window @ 0xd15f220 (native @ 0xd15e34c)]

Looks like the 

  EU._simpleAdd(window,"unload",EU._unload)

call in that mess.

Comment 7

[Frédéric Buclin]

pyrzak, which patch added this regression? If the patch has already been checked in upstream, then we should move the bug to Bugzilla.

Comment 8

[Guy Pyrzak]

This is caused by YUI getting added to Bugzilla.

the fix is to remove the unload events in FF from the unload and instead add it to the pagehide event. I will get to work on this when I can unless there is another yui/js person out there who would like to take on this one?

Comment 9

[Guy Pyrzak]

also filed https://sourceforge.net/tracker/index.php?func=detail&aid=2091763&group_id=165715&atid=836476 against YUI

Comment 10

[Max Kanat-Alexander]

(In reply to comment #9)
> also filed
> https://sourceforge.net/tracker/index.php?func=detail&aid=2091763&group_id=165715&atid=836476
> against YUI

  Boris: YUI says WONTFIX for that, do you want to respond on the linked bug? (If they don't fix it, there's a chance that we won't fix it either.)

Comment 11

[Boris Zbarsky [:bzbarsky]]

I commented, but I'm not going to spend time setting up an account there.

Honestly, this is pretty negatively impacting my work with bugzilla: I use browser history to go through things I just did a _lot_, and this bug plus whatever HTTP caching issue there seems to be which prevents me seeing the results of POSTs makes that well-nigh impossible.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Further it will cause dataloss. I was already affected by this multiple times now. Writing a comment, re-setting some flags and checking the history.. Ouch! When you go back you will get the alert. Either you cancel it and loose all modifications or clicking yes and run into a mid-air collision. This impacts the work on Bugzilla drastically. Please fix that!

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I don't touch as many bugs a day as bz, but I do also go back and forward between bugs (and between bugs and patches, where bfcache at least works in direction) extensively, and there is a really noticeable delay.  This (plus whatever is slowing down pageload significantly) makes me feel like I'm using Bugzilla on dialup again; I can't imagine what it feels like to Bugzilla users who actually *are* on dialup :(

(In reply to comment #8)
> the fix is to remove the unload events in FF from the unload and instead add it
> to the pagehide event.

If you're going to be hacking this, please be sure to check for Gecko rather than just Firefox.

Comment 14

[Guy Pyrzak]

boris, smokey, I was wondering if you all could give me more specific info about the slow down, for example are we 100% sure it is the JS? Try turning off the JS and does it do what you all were used to? 

If it is all the JS, then I would like to get some info about the before and after (although if that is the case I can figure it out myself with turning off the JS). 

I'm not sure i have as accurate an idea as you two do, so please let me know. I am equally interested in fixing this for you guys.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> boris, smokey, I was wondering if you all could give me more specific info
> about the slow down, for example are we 100% sure it is the JS? 

Yes.  See comment 0 and comment 6.  If I turn JS off, bfcache works again.

Comment 16

[Guy Pyrzak]

ok, we've got the fix and tested it (the solution from the YUI guys), we'll make sure to check for any gecko based browser. This didnt seem to work for webkit though. I'm not sure if they have BF cache.

Comment 17

[Guy Pyrzak]

Attachment: reverts back to YUI 2.3.1 which doesn't break bf_cache for bmo

Comment 18

[Guy Pyrzak]

caused by YUI upgrade. Revert fixes it.

Comment 19

[Max Kanat-Alexander]

Comment on attachment 336786 [details] [diff] [review]
reverts back to YUI 2.3.1 which doesn't break bf_cache for bmo

You replaced calendar.js with a non-minified version.

Comment 20

[Dave Miller [:justdave]]

(In reply to comment #19)
> (From update of attachment 336786 [details] [diff] [review])
> You replaced calendar.js with a non-minified version.

Please make a delta patch from the last one for that, I already commited it.

Comment 21

[Guy Pyrzak]

Attachment: delta patch to change calendar with minimized version

Comment 22

[Max Kanat-Alexander]

Comment on attachment 336983 [details] [diff] [review]
delta patch to change calendar with minimized version

That doesn't look like a delta--I don't see a change to the non-monified calendar.js?

Comment 23

[Guy Pyrzak]

Attachment: delta patch to change calendar with minimized version V2

forgot to run update first

Comment 24

[Max Kanat-Alexander]

Comment on attachment 336989 [details] [diff] [review]
delta patch to change calendar with minimized version V2

Lookz gewd 2 me.

Comment 25

[Johnny Stenback (:jst)]

Yeah, this is bad, what's holding this up?

Comment 26

[Dave Miller [:justdave]]

(In reply to comment #25)
> Yeah, this is bad, what's holding this up?

me being on call last week and getting paged out of bed 10 times a night all week and being dead tired; and still catching up on bugmail since then.

I'll get this committed and deployed tonight.

Comment 27

[Dave Miller [:justdave]]

Or today since I fell asleep on it again. :(

Committing to: /var/www/html/bmo/3.2/
modified js/yui/calendar.js
Committed revision 6145.

Comment 28

[Dave Miller [:justdave]]

This is deployed to production, you'll probably have to shift+reload to pick it up, since the js files tend to get cached by your browser.

Comment 29

[Max Kanat-Alexander]

Did you commit the "reverts back" patch, too? (The one with review-; I didn't see the commit message.)

Comment 30

[Dave Miller [:justdave]]

Yeah, I did, see comment 20.  That's why I asked for a delta patch instead of a replacement. :)

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Max, does it mean it isn't completely fixed yet? I ask because I can still see it on bmo with the following steps:

1. Log-off
2. Goto https://bugzilla.mozilla.org/show_bug.cgi?id=453459
3. Log-in (redirected to the above link)
4. Click on History
5. Go back

I still get ask if I want to resent the information.

Comment 32

[Max Kanat-Alexander]

(In reply to comment #31)
> 1. Log-off
> 2. Goto https://bugzilla.mozilla.org/show_bug.cgi?id=453459
> 3. Log-in (redirected to the above link)
> [snip]

  No, that's normal, you logged in and so you actually posted data.

  If you're seeing it on some other page, shift-refresh to get the new JS files.

Comment 33

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Ok, but following steps should use bfcache, right?

1. Open a bug
2. Goto History
3. Go back

With step 3 the page gets completely reloaded and it takes around 4 seconds until it has been finished. It's still very annoying and doesn't seem to be fixed when comparing to the "View Bug Activity" behavior on Bugzilla 3.0 branch.

Comment 34

[Frédéric Buclin]

(In reply to comment #28)
> This is deployed to production, you'll probably have to shift+reload to pick it
> up, since the js files tend to get cached by your browser.

Is this really deployed to production? AFAICS, this is only deployed on https://bugzilla-stage-tip.mozilla.org/. Because none of the recent checkins is visible on b.m.o, only on stage.

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It seems to work now even on bmo.

(In reply to comment #32)
> (In reply to comment #31)
> > 1. Log-off
> > 2. Goto https://bugzilla.mozilla.org/show_bug.cgi?id=453459
> > 3. Log-in (redirected to the above link)
> > [snip]
> 
>   No, that's normal, you logged in and so you actually posted data.

And this is not normal but also a regression. Please compare the given steps with the 3.0 branch on landfill by using following url:

http://landfill.bugzilla.org/bugzilla-3.0-branch/show_bug.cgi?id=3405

You will see when going back from the activity page that there is no sheet which asks for resending the data. Perhaps it should be filed as a separate bug?

Comment 36

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #34)
> (In reply to comment #28)
> > This is deployed to production, you'll probably have to shift+reload to pick it
> > up, since the js files tend to get cached by your browser.
> 
> Is this really deployed to production? AFAICS, this is only deployed on
> https://bugzilla-stage-tip.mozilla.org/. Because none of the recent checkins is
> visible on b.m.o, only on stage.

When I shift-reload this bug, click the History link up in the Modified line, and press back, I'm still getting a slow load and lots of "Waiting for bmo" "Contacting bmo" "Transferring data from bmo" messages in the status bar while I wait for this bug to load.  It certainly doesn't seem like a fix is on production-bmo (or else the fix is not working).

Comment 37

[Boris Zbarsky [:bzbarsky]]

> No, that's normal, you logged in and so you actually posted data.

Yes, but the point is that we shouldn't be doing _any_ server access if bfcache is working.  So POST vs GET doesn't matter: we're just restoring the DOM, not hitting the HTTP layer at all.  If things work.

Comment 38

[Dave Miller [:justdave]]

The patches that are on here are deployed on bugzilla.mozilla.org.  I deployed this one and the EXPIRED thing here first before I merged in the rest of the stuff from the 3.2 branch.  So if this is still happening on bmo then this bug isn't really fixed.

(In reply to comment #35)
> And this is not normal but also a regression. Please compare the given steps
> with the 3.0 branch on landfill by using following url:
> 
> http://landfill.bugzilla.org/bugzilla-3.0-branch/show_bug.cgi?id=3405

This is not a valid test, because you're not using SSL.  The fact that SSL is in use blows away some of Firefox's normal caching behaviors.

Try it with https://landfill.bugzilla.org/bugzilla-3.0-branch/show_bug.cgi?id=3405 instead.

Comment 39

[Boris Zbarsky [:bzbarsky]]

ssl vs non-ssl doesn't affect bfcache behavior.

Comment 40

[Boris Zbarsky [:bzbarsky]]

So this is odd. I can confirm that the pageload is much faster now, for whatever reason.  At the same time, we're still not hitting the bfcache (based on some stepping through in gdb), because the unload listener added with the stack of comment 6 is still there, as far as I can tell.

Comment 41

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Based on Boris comment we should reopen this bug.

Comment 42

[Johnny Stenback (:jst)]

Yeah, I can confirm that this is really not fixed yet.

Comment 43

[Wayne Mery (:wsmwk)]

quite painful on a hotel - less than optimal broadband - connection

Comment 44

[Samuel Sidler (old account; do not CC)]

(In reply to comment #43)
> quite painful on a hotel - less than optimal broadband - connection

You're telling me. Bugzilla from Thailand was atrocious. I'm not sure how Gary manages from Singapore. ;)

But really, what work can I do to help get this fixed? It's clearly still a problem.

Comment 45

[Wayne Mery (:wsmwk)]

fixing bug 457116 may help some.  I also note there that removing most of my saved searches from the footer seemed to help.

Is there any bug that addresses time to complete queries (not render)? That seems to have gotten worse, but it wouldn't be this bug.

Comment 46

[Frédéric Buclin]

Did someone investigate if there was a bug in Firefox itself?

Comment 47

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #46)
> Did someone investigate if there was a bug in Firefox itself?

Interesting question. I tried it with Firefox 2.0.0.17 in parallel and noticed a big performance win. While I had to wait around 10s to go back from an attachment with 3.0.4pre it only takes ~1s with 2.0.0.17. A good test case will be bug 340535 with 253 comments at the moment. That behavior gives really the feeling that we have a regression in Firefox 3.

Comment 48

[philippe (part-time)]

(In reply to comment #47)

Where you logged in into bugzilla with Fx 2.0.0.17?

I just did a test: with bug 340535, clicking on 'history link' and back;
* FX 3, not logged in: fast
* Camino 2.0a1pre, logged in into bugzilla: rather slow, took several seconds to go back to the bug page
* Minefield latest, logged in: same as Camino.
* WebKit latest nightly, not logged in: real slow, statusbar shows 'connecting to b.m.o'. I've never seen WebKit so slow.

The 'history' link has always been acceptably fast, I see the issue much more often with attachements, esp if those are images.

Comment 49

[Frédéric Buclin]

Could someone CC some of the bfcache experts here? I don't know who they are. :) And if the regression is confirmed, then we should close this bug and file a separate one in the appropriate product/component.

Comment 50

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I was able to identify the problem, at least for me. As what it looks like Firebug is causing this problem. After some suspending/resuming actions it  resolves the issue and bfcache is working properly and pages are displayed immediately when going back and forward. Anyone who can confirm that?

Comment 51

[Samuel Sidler (old account; do not CC)]

(In reply to comment #49)
> Could someone CC some of the bfcache experts here?

I believe Boris qualifies as that.

Comment 52

[philippe (part-time)]

(In reply to comment #45)
> I also note there that removing most of my
> saved searches from the footer seemed to help.

Yep, that improves things a lot here.

Comment 53

[Frédéric Buclin]

How many saved searches do you have in your footer? I have 38, but the number shouldn't matter at all.

Comment 54

[philippe (part-time)]

(In reply to comment #53)

I had twelve, reduced to four. It makes a real difference. That may also sort of confirm my comment 48: when not logged in, no saved searches.

Doesn't explain the WebKit slowness, though. But maybe I just hit b.m.o on a slow moment when I tested it there.

Comment 55

[Frédéric Buclin]

(In reply to comment #54)
> I had twelve, reduced to four. It makes a real difference.

Could be due to bug 364162.

Comment 56

[Frédéric Buclin]

(In reply to comment #48)
> I just did a test: with bug 340535, clicking on 'history link' and back;

Could you run the same tests again, now with JS disabled?

Comment 57

[John J. Barton]

(In reply to comment #50)
> I was able to identify the problem, at least for me. As what it looks like
> Firebug is causing this problem. After some suspending/resuming actions it 
> resolves the issue and bfcache is working properly and pages are displayed
> immediately when going back and forward. Anyone who can confirm that?

This is just FYI regarding Firebug: listens for 'pagehide' on top windows and 'unload' on frames. If pagehide fires and the page is not cached, then listens for unload.  I know of one bug involving Firebug losing track after forward and back.

Comment 58

[Tony Mechelynck [:tonymec]]

(In reply to comment #47)
> (In reply to comment #46)
> > Did someone investigate if there was a bug in Firefox itself?
> 
> Interesting question. I tried it with Firefox 2.0.0.17 in parallel and noticed
> a big performance win. While I had to wait around 10s to go back from an
> attachment with 3.0.4pre it only takes ~1s with 2.0.0.17. A good test case will
> be bug 340535 with 253 comments at the moment. That behavior gives really the
> feeling that we have a regression in Firefox 3.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18pre) Gecko/2008092803 BonEcho/2.0.0.18pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080928001417 SeaMonkey/2.0a2pre

Tried to compare it by opening bug 340535 in a new tab. No really significant difference between BonEcho [aka Fx2 nightly] and SeaMonkey when logged in (maybe 10 seconds or so, counting mentally, not clocking). Slightly faster when not logged-in (tested in BonEcho), but much less than 10 times faster.

Comment 59

[Boris Zbarsky [:bzbarsky]]

> Could someone CC some of the bfcache experts here?

That would be me, or at least the closest you'll find active.  Seriously, comment 40 is the current state of things as far as I can tell.  If someone can point me at a previous-version install of Bugzilla, I can check what the behavior was there.

Comment 60

[Frédéric Buclin]

I was talking with pyrzak right now and he said he knows how to fix this issue:

<pyrzak> Disabling the current behavior is trivial:

YAHOO.util.Event._simpleRemove(window, "unload", YAHOO.util.Event._unload);

He said he would do it tonight. Let's wait for his patch to be attached, tested and applied to b.m.o, then let's discuss again if the issue is still here. :)

Comment 61

[Dave Miller [:justdave]]

(In reply to comment #59)
> If someone can point me at a previous-version install of Bugzilla, I can check
> what the behavior was there.

https://bugzilla-stage.mozilla.org/ is still there running the old 3.0 code with an old snapshot.  I was going to clone the current production into there (and move to 3.4/trunk on bugzilla-stage-tip) eventually, but I haven't gotten around to it yet.

Comment 62

[Dave Miller [:justdave]]

except that the database moved and the config didn't get updated, should have that fixed in a few minutes.

Comment 63

[Wayne Mery (:wsmwk)]

some stopwatch timings on using this bug as the testcase on a dell AMD Turion, wireless G. Connection varies between 100-500KB/sec inbound, enough to account for variation in times. Each test was run 5-6 times. clean profile.

              logged   not        logged in* not logged in
              in*      logged in  js off     js off
FF 2.0.0.12   6.2-8.3  5.1-6.4    4.2-4.9    3.6-4.1
FF 3.0.2      4.4-5.8  3.7-4.2    2.7-3.7    2.7-3.5
FF 3.1b1pre   4.0-4.8  3.7-4.7    3.1-4.1    2.6-3.7

* bz account with editbugs and 6 saved searches

conclusions:
- v2.x looks like slower than v3.anything
- v3.1 looks faster than v3.0 (mixed results)
- js off ~1 second faster all versions
- not logged in ~ 1 second faster (js=off/on minor or no impact)
- type of account maybe makes ~10% difference

sadly, not able to control for connection speed nor bugzilla response time.

3??k logged in, with saved sesarches (didn't get to save it before comment 61+62
344k logged in, no saved sesarches
313k logged in, "no privs" account
288k not logged in
NOTE: 36k keywords array is ALWAYS loaded, even when not logged in (Bug 457116)


comment 45 based on reducing 61 saved searches to 7.

Comment 64

[Guy Pyrzak]

Attachment: Patch v1

Comment 65

[Max Kanat-Alexander]

(In reply to comment #64)
> Created an attachment (id=340869) [details]
> Patch v1

  I have a few questions:

  Is that unload listener only added when you use certain YUI controls, or is it added by dom-event?

  How bad are the memory leaks that this will cause in IE?

  Why do you have to use a seemingly-private function (that begins with an underscore) to remove the event?

Comment 66

[Frédéric Buclin]

(In reply to comment #65)
>   Why do you have to use a seemingly-private function (that begins with an
> underscore) to remove the event?

I can answer this question: because one of the admins of the YUI project told him to do this.

Comment 67

[Guy Pyrzak]

(In reply to comment #65)
>   Is that unload listener only added when you use certain YUI controls, or is
> it added by dom-event?
It is added by event. See the code in YUI for more info
 
>   How bad are the memory leaks that this will cause in IE?
No idea! We could make this only happen for firefox, just an if statement.
 
>   Why do you have to use a seemingly-private function (that begins with an
> underscore) to remove the event?
YUI dude said so...

I don't really have many answers for this one, I'm not even sure if this does anything(i don't know how to observe the bfcache)! So perhaps Boris should review this instead of max.

Comment 68

[Boris Zbarsky [:bzbarsky]]

> i don't know how to observe the bfcache

See comment 2 for tasty easy-to-follow steps to do just that.  ;)

Comment 69

[Frédéric Buclin]

(In reply to comment #68)
> See comment 2 for tasty easy-to-follow steps to do just that.  ;)

Without the patch, I get the bug page. With the page, I get "OK".

Comment 70

[Frédéric Buclin]

(In reply to comment #69)
> Without the patch, I get the bug page. With the page, I get "OK".

Sorry: s/the page/the patch/.

IE has <!--[if IE]> <![endif]-->. It would be great if Gecko had something similar, so that we could do it for Gecko-based browsers only. (I think we already suggested this somewhere.)

Comment 71

[Guy Pyrzak]

Attachment: Patch v2

Comment 72

[Frédéric Buclin]

I need to move this bug back into the Bugzilla product so that I can set flags correctly. Moreover, pyrzak's patch must land upstream; it's not specific to b.m.o.

Comment 73

[Frédéric Buclin]

Comment on attachment 340980 [details] [diff] [review]
Patch v2

Seems to work fine, and the test condition will only remove the listener if it's a Gecko-based browser. So this eliminates mkanat's worries about memory leaks in IE. r=LpSolit

Comment 74

[Frédéric Buclin]

Obviously a blocker. I would still like a second review before approving it.

Comment 75

[Dave Miller [:justdave]]

Patch v2 is now deployed on https://bugzilla-stage-tip.mozilla.org/

Comment 76

[Frédéric Buclin]

bz, could you test on the installation given in comment 75?

Comment 77

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #75)
> Patch v2 is now deployed on https://bugzilla-stage-tip.mozilla.org/

bfcache seems to be working for me in a few simple tests on that install--except changes made to the keyword field (but not committed before leaving the page) aren't remembered on going back; I assume that will go away when the keyword chooser is removed?

Comment 78

[Reed Loden [:reed]]

(In reply to comment #77)
> I assume that will go away when the keyword chooser is removed?

Removed?

Comment 79

[Max Kanat-Alexander]

My concern is that now we have a working bfcache, are some of our onload (or onDOMReadyState) events unnecessary? Will this break YUI in any way in Firefox?

Comment 80

[Max Kanat-Alexander]

(In reply to comment #78)
> (In reply to comment #77)
> > I assume that will go away when the keyword chooser is removed?
> 
> Removed?

  We removed the chooser upstream. bmo has apparently decided to use an unreviewed patch to put in a different keyword autocomplete system.

Comment 81

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #80)
> (In reply to comment #78)
> > (In reply to comment #77)
> > > I assume that will go away when the keyword chooser is removed?
> > 
> > Removed?
> 
>   We removed the chooser upstream. bmo has apparently decided to use an
> unreviewed patch to put in a different keyword autocomplete system.

Boy, that's not at all clear from bug 452734 :P

Comment 82

[Guy Pyrzak]

(In reply to comment #79)
> My concern is that now we have a working bfcache, are some of our onload (or
> onDOMReadyState) events unnecessary? Will this break YUI in any way in Firefox?

I dunno (that's a good qa question) but we can't get rid of the onDOMReady stuff b/c IE and safari and other browsers still need it (only firefox has bfcache as far as I know). I would hope those events wouldn't get fired when bfcache is being used.

Comment 83

[Frédéric Buclin]

As none of us really knows the answer for comment 79, we will check in this patch as is and see what happens.

Comment 84

[Boris Zbarsky [:bzbarsky]]

> bz, could you test on the installation given in comment 75?

Looks good to me.

Comment 85

[Guy Pyrzak]

Checking in template/en/default/global/header.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/header.html.tmpl,v  <--  header.html.tmpl
new revision: 1.59; previous revision: 1.58
done


Checking in template/en/default/global/header.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/header.html.tmpl,v  <--  header.html.tmpl
new revision: 1.56.2.3; previous revision: 1.56.2.2
done

Comment 86

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Bfcache works fantastic now when navigating forwards and backwards through bugs. Looks like it's fixed now. Boris, can you agree?

Comment 87

[Boris Zbarsky [:bzbarsky]]

I'm not getting that on bmo in my debug build.  I've tried shift-reloading and I've tried clearing cache, but there is still an unload listener...

Comment 88

[Dave Miller [:justdave]]

This isn't on the production bmo server yet, just on the staging server mentioned in comment 75.  If you sign off on it there I'll deploy it.

Comment 89

[Boris Zbarsky [:bzbarsky]]

Oh.  I did that in comment 84.  ;)

Comment 90

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #88)
> This isn't on the production bmo server yet, just on the staging server
> mentioned in comment 75.  If you sign off on it there I'll deploy it.

Is there an ETA for getting this deployed on bmo?  It'd probably relieve half of my pain from bug 453584....

Comment 91

[Frédéric Buclin]

(In reply to comment #90)
> Is there an ETA for getting this deployed on bmo?

As soon as someone helps justdave resolving conflicts: http://pastebin.mozilla.org/555012

Comment 92

[Dave Miller [:justdave]]

Or we can just skip merging the rest of 3.2 and just take this.

Committing to: bzr+ssh://dm-bugstage01/var/www/html/bmo/3.2/
modified template/en/default/global/header.html.tmpl
Committed revision 6151.

And deployed to production.

Comment 93

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Just a question. Does bfcache doesn't catch the following trace?

1. File a new bug with an attachment or just attach an attachment to an already existing bug
2. Commit the change
3. Click on the newly added attachment
4 [review]. Click the back button

Why the former page cannot be displayed without reloading its content? It's really annoying because you cannot go back directly to the bug report after you did step 3.

Comment 94

[Boris Zbarsky [:bzbarsky]]

If you don't get back the page from after step 2, then bfcache didn't happen.

Comment 95

[Tony Mechelynck [:tonymec]]

(In reply to comment #9)
> also filed
> https://sourceforge.net/tracker/index.php?func=detail&aid=2091763&group_id=165715&atid=836476
> against YUI

This bug has been moved to a new tracking system with little indication at the old address of where to go for the followup; then the original bug has been CLOSED which forbids adding new comments (such as this one). After jumping through several hoops, I found the new ticket (ASSIGNED) at http://yuilibrary.com/projects/yui2/ticket/2091763