Closed Bug 438362 Opened 13 years ago Closed 11 years ago
Replace <strike>"munched"</strike> text with normal text and provide alternative amusement
That "Please wait while your bugs are <strike>munched</strike> retrieved" joke has got old really fast. It's just not amusing any more. Please can we remove the strikeout part, or even just switch to "Please wait..."? And the blurry 3d animation of a dino head eating a leaf, as well. For one, most current progress animations (Mac OS X wheel, Firefox dots, Gnome dots) are circular (as in, the last frame is the same as the first) for a reason. Non-circular ones are more frustrating. Gerv
I like it, and it's not harming anybody. Recommending WONTFIX.
Assignee: query-and-buglist → nobody
Component: Query/Bug List → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Version: unspecified → other
The last frame is the same as the first one, it's not blurry, and it's a bug, not a leaf, that he's eating. The text is old, yeah, but I still think the graphic is cute. Maybe we can refresh it with something better when we do the Bugzilla 3.2 upgrade (since that'll be a bigger upgrade again, and more things will change than just that).
You are right about the first and last frames, but it looks very like a leaf to me. And actually, I object to the words far more than the graphic. Let's keep this bug about the words. The thing is, I have to stare at it while I'm waiting for my bugs to arrive, and all I can think is "that's just not funny". Gerv
This patch does what this bug requests. It also removes the alt text on the image; the image is decorative, and therefore (as I understand it) should have no alt text. Gerv
Attachment #325559 - Flags: review?(justdave)
Comment on attachment 325559 [details] [diff] [review] Patch v.1 Looks good to me.
Attachment #325559 - Flags: review?(justdave) → review+
12 years ago
Assignee: nobody → gerv
Committing to: bzr+ssh://dm-bugstage01.mozilla.org/bzr/bmo/3.0/ modified template/en/custom/list/server-push.html.tmpl Committed revision 5190. This will get picked up next time we push the site.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 325559 [details] [diff] [review] Patch v.1 Sorry, but I'm against this change. There's nothing wrong with having a little humor with Bugzilla's search page. We don't have to be "professional" in everything we do, and that's against the Mozilla way.
Attachment #325559 - Flags: review-
I don't understand taking out the word munch if the dino is still going to be there. Also, you shouldn't take out alt text for an image without replacing it. I disagree with the arguments presented to make a change like this. "It annoys Gerv" just doesn't seem logic based enough. Nor does "it has a patch." Maybe it annoys Gerv for a good reason, but there should at least be a good reason.
Aww. I very much liked Chompy. I've not heard anyone complain about it before, and it was well-received when it landed. I have a better animation (APNG!) from the creator: http://people.mozilla.com/~dolske/apng/chompy2.png
Reed: Indeed, nothing wrong with a little humour. But if I told you the same joke ten times every day, you'd get bored of it eventually, right? Majken: there's nothing inconsistent about having a dino animation without the poor joke oops-I-said-something-'silly'-let-me-retract-it joke accompanying it. Not all images require alt text. You aren't supposed to put any on decorative images. In fact, sticking in alt text where none was needed was a big complaint a few years ago from the accessibility folks. Justin: that animation looks the same; can you give us a run-down on the differences? Gerv
(In reply to comment #10) > Reed: Indeed, nothing wrong with a little humour. But if I told you the same > joke ten times every day, you'd get bored of it eventually, right? No, not at all. We have many long-standing jokes in the Mozilla world. Just because you're tired of it doesn't mean everybody else is.
(In reply to comment #10) > Justin: that animation looks the same; can you give us a run-down on the > differences? See demo 4: http://people.mozilla.com/~dolske/apng/demo.html Basically, it's smoother and sharper. Though not radically so. > Reed: Indeed, nothing wrong with a little humour. But if I told you the same > joke ten times every day, you'd get bored of it eventually, right? See also: http://youtube.com/watch?v=z-HWXfRKkJU
How about this instead? I spent a few hours today making this, and I think it's quite fun. Click to add more bugs. Gerv
for the record I happened to think it was getting stale, too (the text, not the dino head). We should change that page around periodically anyway, spice it up, show off new tricks, keep people entertained while they wait, etc. :)
Love the bugs crawling around!
This puts a random wikipedia page in an iframe below the bugzilla search message. It's random every time and educational.
Reopening this to get the bugs stuff.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reed: It seems to suck up some CPU power after a minute or so. Wikipedia this is not a good idea what so ever. Might get http://en.wikipedia.org/wiki/Cunnilingus or some other sexual topic popping up.
(In reply to comment #19) > Reed: It seems to suck up some CPU power after a minute or so. > On my travel laptop, which is an old machine, it pegs the CPU, and I'd have to use userContent.css to kill all the images. I think it's hilarious, but I'm not sure how amused I'd be after a while given the CPU usage.
About pegging the CPU: optimizations welcome. But it's important to note that it only fires when the mouse is over the tab. Switch tabs or applications and you'll be fine. We could also lower the frame rate if necessary, or the starting number of bugs. richardus: I think it's important to have something which people can start and stop "doing" at any time - because we don't want them to be in the middle of reading something when the results turn up and the page changes. That's why I didn't implement anything like Tetris or whatever. The bugs seem perfect for this. Gerv
(In reply to comment #14) > Created an attachment (id=325998) [details] > 'bugs' demo <center> is complete useless here and should be removed. Why not vertically centering the hole thing? (makes it more independent from window size) <table style="height:80%" align=center> <tr><td align=center> <img src="http://people.mozilla.com/~dolske/apng/chompy2.png" alt=""> <h1>Please wait while your bugs are retrieved.</h1> </table> (Yes, it's table layout, but currently impossible to do with CSS)
Dolske: gerv@otter:bmo$ ls -l chompy2.png -rw-r--r-- 1 gerv gerv 288313 2007-07-14 05:38 chompy2.png gerv@otter:bmo$ ls -l skins/custom/images/mozchomp.gif -rw-r----- 1 gerv gerv 89485 2008-04-14 11:18 skins/custom/images/mozchomp.gif Can you do better than a 3x size increase? :-) j.j.: Thanks, but actually I want to set the body to overflow:hidden (so scrollbars don't appear occasionally when a bug goes walkabout) and we need to save space underneath for debug output. So I'm happy with the current markup. I've removed the extraneous <center>, though. I'm going to experiment with Venkman to profile it. Gerv
Here's a first version of a patch. The bugs.js in here has been optimised to reduce parseInts and DOM value access. I didn't find Venkman's profile output very understandable, unfortunately :-( Performance is better, but I can't see how to optimise any more. I still don't have explicit rights to the bug images; I've emailed the author asking for them, although the code they came with is very old so he may not be using that email address any more (it's @aol.com). If not, we might be OK given what it says on the site I got it from. But it's better to ask. Gerv
Comment on attachment 326354 [details] [diff] [review] Bugs patch v.1 This isn't the patch you were thinking of...
How about this one? Gerv
please do not hard code host names into attachments, they break the ability to do things like this: https://test1.bugzilla.mozilla.org/attachment.cgi?id=325998
Attachment #325998 - Attachment is obsolete: true
for reference, you can load attachments at a number of hosts including https://test1.bugzilla.mozilla.org/attachment.cgi?id=326441 https://test2.bugzilla.mozilla.org/attachment.cgi?id=326441 the advantage of not hard coding it is that someone could blacklist scripts from bmo but want to see this one script w/o resubmitting every single bmo window that's open in the application. all the someone has to do is load a test* variant and whitelist it temporarily.
> Please wait while your bugs are retrieved. can we switch to: Please wait while your bugs are digested. It's not even technically wrong, as buglists are a digest (not full)
(In reply to comment #30) > Here's the latest version. Some performance optimisation has been done. The new code is completely missing...
Status: REOPENED → ASSIGNED
A random quip is already displayed on other pages - it could be used here too.
(In reply to comment #27) > Created an attachment (id=326441) [details] > 'bugs' demo SeaMonkey 1.1.12pre: Error: uncaught exception: [Exception... "Not enough arguments" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: https://bugzilla.mozilla.org/attachment.cgi?id=325997 :: <TOP_LEVEL> :: line 229" data: no]
Given that Dave's blogged this, a word of explanation: - The bugs follow the mouse cursor, but if they reach it, they disappear and reappear randomly somewhere else on the page. - Clicking the mouse creates another bug at a random location The result is that you can play "Pied Piper of Hamlyn" as you lead a procession of bugs around the page, or you can try and keep your mouse pointer out of the way as you create more and more bugs, or you can tease an individual bug by waving the pointer around it in circles... the possibilities are endless. Reed: good spot :-) I'll upload the patch again. Gerv
Here's a version which actually has the code in it :-) I've also made it work in Seamonkey 1.x/Firefox 2 - that required one code change, plus messing around with the z-order to avoid hitting the differences between the Gecko 1.8 and Gecko 1.9's handling of that property. Gerv
And here's one which applies cleanly to bzr://bzr.everythingsolved.com/mozilla/3.2 . Gerv
(In reply to comment #21) > About pegging the CPU: optimizations welcome. But it's important to note that > it only fires when the mouse is over the tab. Switch tabs or applications and > you'll be fine. We could also lower the frame rate if necessary, or the > starting number of bugs. This isn't true, for me at least, using the demo timeless attached the bugs are wandering from the moment the page loads, regardless of where my mouse is. I can load it 10 times in background tabs and the bugs are wandering there eating up CPU time. I really don't see why we need to bloat out this when bugzilla is already slow enough to access for me, is not just a simple throbber enough.
Dave: you are quite right; I stop the movement on mouseout but it seems that if the page loads with the mouse not over it (like in background tabs), it auto-starts and never stops. We can fix this by having it stopped by default, and only starting it on a mousemove/mouseover. That's a trivial change - the initial value of the "paused" variable should be "true" rather than "false". I'll put that in to the next patch when one is needed, or if it's now perfect, it can be changed before checkin. Gerv
For fun I wanted to see how many bugs I could get going on the screen using timeless's demo. Once you get up to around 100 bugs you get quite the slowdown in both the throbber and the bugs (no surprise there). Navigating back to other tabs was fine. Feature suggestions : . Is there a way to kill the additional bugs you create by mouse clicking? Maybe permanently kill off bugs greater than the initial starting amount when they hit the pointer? . How about a "squish" graphic when a bug hits the pointer?
(In reply to comment #39) > Feature suggestions : No :-) This is a quick amusement, not a fully-fledged web game. Gerv
For what it's worth, people have posted humor ideas on Dave's blog: http://www.justdave.net/dave/2008/08/28/what-do-you-want-to-see-while-you-wait/ . Mind you, no one there is volunteering to actually implement any of these. ;-)
Comment on attachment 335862 [details] [diff] [review] Patch v.5 This is something for justdave to review, not me.
Attachment #335862 - Flags: review?(mkanat) → review?(justdave)
re comment 39, for the record, my demo was just gerv's repackaged to work around an error in his coding (as explained in comment 27 and comment 28). I meant to quote ss, but unfortunately I'm not home right now, so what follows is a use case from the current animation (which we propose is a requirement for a replacement).... ss uses the current animation to measure query speed (X munches to run a query). A complicated query may take 3-4 munches, a fast query will not require any munches, and a medium query may only take 1 munch. it's important that there be some way to measure munches (query complexity/speed), it enables a number of things including determining if a query is inefficient, whether the server is loaded, if there's a regression in the service itself, and just comparing queries. the exact implementation of how you make a query measurable is not something we're requiring, however it should be: easily discovered, easily tracked, and easily measured. it should also be consistent (so random acceleration/deceleration of an animation would be a bad thing) and it should not require user interaction. it's probably possible to simply give the user a clock and retain the timing of a query once the page loads, however we're not specifically asking for that (and I may at some point file a bug specifically for such a thing). note that while I know about &debug=1, that's a manual thing i'd have to enable, and similarly using a stop watch outside of the browser is painful.
This is an updated patch against the latest bzr b.m.o. 3.4 code, for ease of application before (or just after) the upgrade :-) Gerv
Summary: No more "munched", please → Replace <strike>"munched"</strike> text with normal text and provide alternative amusement
This is in place on bugzilla-stage-tip. It takes a few seconds to start up, so it's not even testable unless you find a really time-consuming query to run. When it does start, I can add bugs by clicking, but they don't seem to move around at all.
OK, I'll look at that today. It's easier to test when you can hack Bugzilla not to go past the interstitial page! Gerv
It was a heisenbug. onload() doesn't fire for multipart/x-mixed-replace. But of course, all the demos and all the testing either called exit() after the interstitial page had been shown, or were standalone like the one attached to this bug! Trying to examine the problem made it go away. The attachment replaces the onload event handler with a setTimeout, which should work. And I've worked out how to debug it properly; hack buglist.cgi to sleep() instead of exit(). Gerv
modified skins/custom/bugs.js Committed revision 6695. We can try it out after the db reload finishes (it'll be a few hours).
11 years ago
This got deployed. Followup issues (and complaints) are being dealt with on bug 528871.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → FIXED
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.