[00:49] <Makyo> Rebase hates me.  Anyway.  jujugui lf review/qa (sandbox, 2000 units, watch the inspector for delays) https://github.com/juju/juju-gui/pull/14
[00:50] <hatch> i'll take it
[00:50] <gary_poster> thank you.  also looking at it but won't have time for review
[00:51] <hatch> heh this diff is very confusing
[00:52] <hatch> hmm Makyo  very intersting
[01:05] <gary_poster> Makyo, hatch, I'm seeing maybe a half second shaved off of the pauses as I scroll with 2000 units if I compare local repo with comingsoon.  Is that what I should expect to see, or do you expect the change to be more dramatic?  Maybe I did something wrong
[01:07] <Makyo> gary_poster, not seeing any pauses, here..
[01:08] <gary_poster> Makyo, ack. :-/ I looked at app/views/viewlets/service-overview.js and saw changes you have in the diff
[01:08] <gary_poster> so I do have your changes
[01:08] <gary_poster> I can try make clean
[01:10] <gary_poster> nope, no change
[01:11] <Makyo> Takes 10s for 2000 units to render on comingsoon for me,  1.5s locally.  No delays scrolling in either, though.
[01:12] <gary_poster> ah, weirdness: filesystem says one code, but browser says another
[01:12] <gary_poster> trying something
[01:13] <gary_poster> no
[01:14] <gary_poster> weird!  Makyo good news is that it's something on my system :-/
[01:17] <gary_poster> Makyo, awesome!  weird cache issue on my side; has not happened in a long while.  had to clear cache.  Sorry for false alarm.  Looks great!
[01:18] <gary_poster> I need to grok the branch tomorrow so I can see what you mean by your comments
[01:19] <Makyo> Oh!  Cool :)
[01:19] <Makyo> Yeah, np
[01:31] <gary_poster> Makyo would you mind explaining what you did to the team on the Friday call, as a way of giving us all d3 insight?
[01:32] <Makyo> Definitely.  Will make a card with notes for myself.
[01:32] <gary_poster> thank you
[01:33] <gary_poster> made card.  please feel free to take over :-)
[01:33] <gary_poster> running away.  have a good night!
[12:31] <bac> hi frankban
[12:31] <frankban> morning bac 
[12:32] <bac> frankban: since you are the world's expert on using Mock and MagicMock could you give me a hand with mocking 'open'?
[12:33] <frankban> :-)
[12:33] <bac> frankban: i've got this test:  http://paste.ubuntu.com/6555806/ -- the MagicMock that is returned by the mocked open is not being called.
[12:34] <bac> if i step into the function, the fd returned from the mocked open is a MagicMock and it is being called, but the  object accessible in the calling context is not.
[12:34] <frankban> bac: does it work using '__builtin__.open'?
[12:34] <bac> i've tried using michael's instructions here: http://www.voidspace.org.uk/python/weblog/arch_d7_2010_10_02.shtml#e1188
[12:34] <bac> i've not tried builtin.  good idea
[13:04] <gary_poster> frankban, fwiw I am reviewing your branch
[13:05] <frankban> gary_poster: thank you!, Brad will start the second review in minutes
[13:05]  * frankban lunches
[13:45] <dimitern> gary_poster, hatch, hey guys
[13:45] <gary_poster> hey dimitern .  thanks for work on charm upload: looking cool
[13:46] <dimitern> gary_poster, hatch, we had a bit of discussion about the charm upload implementation
[13:46]  * gary_poster listens
[13:46] <gary_poster> hatch is probably still sleeping in his timezone
[13:46] <gary_poster> or at least not started yet
[13:46] <dimitern> gary_poster, hatch, and some concerns were raised that using multipart/form-data, while being more standard-based is less efficient for bandwidth due to the encoding required
[13:47] <gary_poster> so this POST vs PUT?
[13:47] <dimitern> no matter, at leas he'll be pinged and see the conversation later if i include him :)
[13:47] <gary_poster> :-) cool
[13:48] <dimitern> so, encoding a sub-10MB charm inside a multipart form is not a big deal (some 25% increase in size)
[13:48] <rogpeppe> gary_poster: the question is: is it hard for you to generate a POST with an application/octet-stream body containing the zip file?
[13:48] <dimitern> but I'm told we expect much bigger charms
[13:48] <dimitern> i.e. a binary, non-encoded body
[13:48] <dimitern> ^ re rogpeppe's question
[13:50] <dimitern> gary_poster, the content-type is not a big deal, but 'd prefer it to be application/zip, so we can bail out earlier with a nicer message
[13:50] <gary_poster> dimitern, rogpeppe needs research.  trying to do it quickly.
[13:51] <dimitern> gary_poster, otherwise we're still extracting the archive and reporting any errors, but in a more generic fashion (i.e. "invalid charm format: zip: no header found" or something like it)
[13:51] <rick_h__> compressing client side will be tough
[13:51] <dimitern> rick_h__, I thought we already have the zip packaged before the upload?
[13:52] <gary_poster> rick_h__, this is about octet
[13:52] <rick_h__> gary_poster: oh, ok nvm. 
[13:52] <gary_poster> rick_h__, we will be provided zip *and* there appears to be nice JS zip lib for converting floders to zips
[13:52] <gary_poster> rick_h__, http://stuk.github.io/jszip/
[13:53] <dimitern> also one thing to keep in mind is that we'll be respecting the revision specified in the charm, if possible - i.e. non-conflicting with another charm in state
[13:54] <dimitern> otherwise we'll bump it to the highest in state +1
[13:54] <dimitern> the bumping also occurs if the revision in the charm is lower than the highest in state for the same charm
[13:55] <gary_poster> I like that bit dimitern; I assume the API will give us feedback as to what revision was actually used, so we can report back
[13:55] <dimitern> gary_poster, yes, if you look at the specs https://docs.google.com/a/canonical.com/document/d/1TxnOCLPDqG6y3kCzmUGIkDr0tywXk1XQnHx7G6gO5tI/edit#heading=h.t7svtxl846ha 
[13:55] <dimitern> brb doorbell
[13:56] <rogpeppe> gary_poster: yes, the return from the POST is the charm url which includes the new revision number
[13:56] <gary_poster> great
[13:56] <dimitern> yes
[14:00] <gary_poster> dimitern, rogpeppe I *think* we can do application/zip and application/octet-stream.  We will need to test it on supported browsers, I think, because I don't find a clear cut answer in my searches.  Worst case, though, would be that you have two or three mini-paths, one for zip, one for form-data, and maybe one for octet-stream.  That doesn't sound too bad?  We can give you concrete answer be EoD today as to the res
[14:00] <gary_poster> t?
[14:01] <rogpeppe> gary_poster: it would be nicer if we could avoid the multipart stuff entirely
[14:01] <gary_poster> rogpeppe, of course
[14:02] <gary_poster> rogpeppe, dimitern, so, we will research and give you concrete answers first investigating application/zip (your pref); and then application/octet-stream if we run into trouble with the first.  We will report back today.  Sound good?
[14:03] <rogpeppe> gary_poster: sounds good to me. personally, i'd be more than happy with just application/octet-stream - i can't really see much added benefit from checking the content type, as filesystems don't usually store that.
[14:04] <gary_poster> ack
[14:05] <dimitern> gary_poster, great
[14:05] <gary_poster> cool thanks for update dimitern and rogpeppe.  talk to you soon
[14:05] <dimitern> gary_poster, so, just that you know - I changed the specs to reflect the final version which will be implemented
[14:05] <gary_poster> dimitern, I saw, and also shared it with rest of gui team
[14:06] <dimitern> gary_poster, the most important change is that the body needs to be binary, the Content-Type is not crucial, pending your verification
[14:06] <gary_poster> ack
[14:06] <dimitern> gary_poster, cheers
[14:06] <gary_poster> :-)
[14:07] <hatch> morning
[14:12] <gary_poster> hey hatch.  read backlog for me and I bet you can figure out what I'd like you to answer/research ;-)
[14:15] <hatch> on it!
[14:17] <gary_poster> thanks hatch
[14:19] <hatch> gary_poster so the question is, can we upload uses an octect-stream?
[14:19] <hatch> answer is yes
[14:19] <gary_poster> hatch, on POST as well?
[14:20] <hatch> yep
[14:21] <gary_poster> hatch, great.  includes Safari?
[14:21] <hatch> just confirming safari
[14:21] <gary_poster> cool
[14:22] <gary_poster> hatch also do you want a review of the sticky headers thing?  looks like huwshimi gave you an unofficial +1
[14:22] <hatch> sure, somehow I ended up with over 100 emails lastnight, still going through them
[14:22] <gary_poster> :-) k.  and are you in the middle of a review of Matt's performance branch, or should I take that too?
[14:23] <hatch> going through it 
[14:24] <hatch> another bug with someone using the autocomplete as search results
[14:24] <hatch> heh
[14:26] <hatch> man there is like 0 documentation on safari
[14:26] <bac> gary_poster, frankban: sorry for the vague zope reference, i was thinking instead of the auto-ui generation aspect.  that said, my lack of understanding of the roadmap shouldn't reflect negatively on the work.
[14:27] <rick_h__> hatch: yea, at least we've got a plan on that one, just not done it yet
[14:27] <gary_poster> bac, cool
[14:27] <bac> gary_poster: and i did use a smiley, which covers many sins.
[14:27] <gary_poster> bac :-) <- sins covered
[14:28] <frankban> bac, gary_poster: the reports of me rewriting zope have been greatly exaggerated
[14:28] <gary_poster> lol
[14:28] <bac> :)
[14:28] <bac> frankban: it did seem to come from an unlikely corner
[14:32] <hatch> gary_poster so I can't find anything to confirm/deny the support for octect-stream in safari post - I can hack together a quick node script to test today if you would like
[14:32] <gary_poster> hatch +1 please thank you
[14:33] <gary_poster> hatch, for my own knowledge, where did you confirm octet-stream for chrome et al?
[14:33] <hatch> I just read a few stackoverflow posts where people were having issues with it
[14:35] <gary_poster> heh ok
[14:35] <gary_poster> my google fu was merely insufficient :-)
[14:35] <hatch> it's ok, it happens :D
[14:37] <gary_poster> hatch qa of sticky headers is good.  one idea: the only mildly annoying flickers I see on Ubuntu are chrome, for the top header.  Can we apply the sticky CSS to the top header as soon as the box is drawn?
[14:38] <frankban> bac: yeah, no. the goal is to have a something to describe fields: gary_poster is right we could do that without classes (a namedtuple seems a good candidate). in this case classes seemed to me more natural: they provide a namespace and a factory (__init__). re auto-ui generation: yes those fields will be eventually used to render/validate the urwid env edit form. AFAIK this can be considered similar to zope schem
[14:38] <frankban> as, and to a variety of other python libraries (django.form, wtform etc.)
[14:38] <hatch> I think that should work
[14:38] <hatch> there is also a very odd bug that huw found 
[14:38] <hatch> I'll work on those, did you want to take Makyo 's branch? :)
[14:38] <gary_poster> hatch, sure :-)
[14:39] <bac> frankban: sure, thanks for the explanation
[15:07] <gary_poster> hatch lots of comments and suggestions, but +1.  happy to re-review if desired,
[15:07] <gary_poster> but not necessary.
[15:09] <hatch> thanks
[15:09] <hatch> I fixed the flash in chrome
[15:12] <gary_poster> awesome
[15:12] <hatch> I think that this sticky header code nowhas more lines of comments than code
[15:12] <hatch> hah
[15:13] <gary_poster> +1 :-)
[15:13] <hatch> so much for self documenting code lol
[15:13] <gary_poster> maybe my scrollOffset comment was too much.  <shrug>
[15:16] <hatch> thats only 1 line 
[15:16] <hatch> haha
[15:17] <hatch> the comment that broke the developers back?
[15:17] <gary_poster> :-P
[15:23] <frankban> gary_poster: what do you think about required=False, readonly=False, and then required must be explicitly passed when creating fields?
[15:23] <gary_poster> frankban, I like it.
[15:25] <frankban> gary_poster: the validation is not completely duplicated between the Int and the base fields: the base would complain about 0, but I see your point
[15:26] <gary_poster> cool
[15:28] <hatch> gary_poster when qa'ing Makyo's branch you said that you didn't feel it was more performant? If you want something to compare it to, my branch removes the filters entirely - albeit it has bugs but it'll give you something to compare to.
[15:40] <benji> rick_h__: is the staging charmworld supposed to ingest regularly?  http://staging.jujucharms.com/heartbeat shows that it hasn't since the 8th
[15:41] <rick_h__> benji: hmm, yes I believe so. I'ts using the same cron from the charm as production unless someone turned off the cron job. 
[15:41] <benji> k
[15:45] <Makyo> hatch, it sounds like gary_poster ran into a cache issue, was better after clearing.
[15:46] <hatch> ohh ok 
[15:46] <gary_poster> hatch, thank you.  it turned out to be a caching issue in my browser.  not sure why it triggered.  once I cleared out cache, the code really had a huge & impressive speed increase.  Seems like only slowdown is in simulator
[15:46] <gary_poster> now
[15:46] <hatch> awesomer!
[15:46] <gary_poster> on the order of a fraction of a second, and barely noticeable
[15:46] <gary_poster> yeah definitely
[15:46] <hatch> little bummed that I don't get to write a new implementation
[15:46] <Makyo> :T
[15:46] <hatch> but maybe we'll have to support 10,000 at some point
[15:46] <hatch> :P
[15:47] <gary_poster> :-P
[15:49]  * gary_poster kinda loves seeing pr tests and $$merge$$ work
[15:49] <hatch> yeah I just wish $$merge$$ wasn't so ugly to look at lol
[15:50] <Makyo> jujugui call in 10
[15:50] <gary_poster> ty
[15:50] <gary_poster> hatch, heh, yeah, I suspect patches welcome if we all agree on something
[15:50] <hatch> I'd even go for ::merge:: tbh 
[15:50] <hatch> :D
 not huge imporovement to my eyes, but fine with it if team wants
[15:52]  * gary_poster wishes he remembered ins and outs of Y.merge better
[15:53] <hatch> merge is the easy one, it's mix() that's the impossible one :)
[15:53] <hatch> Y.merge(object[,object]) 
[15:53] <gary_poster> ah right
[15:53] <hatch> Y.mix(who-the-heck-knows)
[15:53] <gary_poster> in merge, which wins?
[15:54] <hatch> last in the line wins
[15:54] <gary_poster> right
[15:54] <gary_poster> thx
[15:54] <hatch> nooooo problem
[15:58] <rick_h__> gary_poster: hatch it's a .ini config key + a doc change. Just say what you want it to be.
[15:58] <gary_poster> :poo:
[15:58] <hatch> +1
[15:58] <Makyo> jujugui call in 2
[15:58] <Makyo> +1
[15:58] <gary_poster> ty
[15:59] <Makyo> I'm glad github comments support both :shipit: and :shit:
[16:02] <Makyo> benji, starting
[16:02] <benji> coming
[16:32] <gary_poster> frankban, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
[16:44] <gary_poster> benji rick_h__ https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 ?
[16:45] <benji> yep
[16:50] <hatch> hey benji, why chiropractor and not massage? 
[17:04] <Makyo> It's rare enough that a webpage has an Esperanto translation that I'm always surprised by it, and remember that Chrome thinks that's my language for some reason.
[17:04] <Makyo> In other news, our Jenkins install has an Esperanto translation :P
[17:05] <hatch> haha oh Esperanto
[17:05] <hatch> I remember the Esperanto bug
[17:31] <Makyo> gary_poster, hatch okay with one review/qa, or should I request another?
[17:31] <hatch> I can do another if you need but the code looked good to me with gary's suggestions
[17:31] <hatch> another qa that is
[17:40] <Makyo> hatch, I'd appreciate it.
[17:40] <hatch> ok on it
[17:41] <Makyo> Sorry, was doing canonicaladmin stuff
[17:42] <hatch> best UX ever in that app
[17:42] <Makyo> Hope I did the end-of-year closure thing right.
[17:42] <Makyo> Hah
[17:43] <hatch> lgtm'd
[17:44] <Makyo> Thanks.
[18:02] <hatch> gary_poster octet is supported across all of our browsers
[18:02] <hatch> on post
[18:02] <gary_poster> awesome, thank you
[18:03] <gary_poster> hatch, I will send a note to dimiter and rogpeppe cc'ing you
[18:03] <hatch> sure thanks, I'll upload the repo so anyone can test if they like
[18:03] <rogpeppe> gary_poster: cool
[18:04] <rogpeppe> hatch: so it's not a problem to upload a zip file as an octet stream with content-type of application/zip ?
[18:05] <hatch> well we can set whatever as a content type
[18:05] <hatch> I just tried streaming a file via post from all of our supported browsers
[18:05] <hatch> I used application/octet-stream
[18:06] <hatch> looks good here with application/zip
[18:07] <hatch> I'll push this repo up so you can see
[18:12] <hatch> https://github.com/hatched/octot-test rogpeppe  gary_poster 
[18:12] <gary_poster> octot?
[18:12]  * rogpeppe likes "octot"
[18:12] <gary_poster> :-)
[18:12] <gary_poster> thanks hatch
[18:12] <hatch> lol typo and I didn't care to change it haha
[18:13] <gary_poster> hatch, reply to my mail with link pls?
[18:13] <hatch> will do
[18:14] <gary_poster> ty
[18:17] <Makyo> Hahah
[18:17] <Makyo> I'm keeping octot. It's perfect.
[18:18] <hatch> lol perfect for what?
[18:18] <Makyo> I dunno, but it beats out octet at whatever it is.
[18:18] <Makyo> Probably perfect for GitHub, actually.
[18:18] <hatch> haha
[18:18] <Makyo> Octotcat.
[18:19] <hatch> Github no longer restricts repo names
[18:19] <hatch> they are namespaced now
[18:19] <hatch> so multiple people can have the same repo name
[18:20] <Makyo> It's been that way since I started using it, at least.
[18:20] <hatch> ohh, maybe I'm remembering some very legacy stuff
[18:20] <hatch> and it just stuck
[18:21] <hatch> ok now what to do....what to do.... *closes eyes and spins around*
[18:21] <hatch> looks like I'm removing more full browser
[18:21] <rick_h__> hatch: there's the search bug 
[18:26] <hatch> search bug?
[18:26] <hatch> you mean that it doens't work like anyone expects it to?
[18:26] <hatch> lol
[18:26] <rick_h__> hatch: yea, quicksearch filting to only showing one result per charm name with importance weighed in like search results
[18:27] <hatch> was that triaged as higher priority than the browser stuff?
[18:27] <rick_h__> hatch: well, at first I thought you were asking
[18:27] <rick_h__> hatch: and it bugs me so if you fix it I get to :) 
[18:28] <hatch> haha
[18:28] <hatch> well I should probably continue on my path of browser stuff
[19:00] <hatch> gary_poster in the hangout, whenever you're ready
[19:31] <bac> oh, yay, the charmworld charm is all bash.
[20:32] <bac> hey benji, if you have a moment could you see if you can successfully 'juju status' to staging.jujucharms.com after 'source orangify'?  i'm getting TLS handshake errors.
[20:32] <benji> bac: sure, let me try
[20:32] <bac> ty
[20:34] <benji> bac: "source orangify" is generating an exception for me
[20:34] <benji> and I have to go to an appointement, like 5 minutes ago :)
[20:34] <benji> sorry I couldn't help
[20:35] <bac> np
[21:02] <hatch> holy so much code removal
[21:08] <hatch> and only 3 test failures
[21:08] <hatch> w00t
[21:27] <hatch> rick_h__ hey are you around?
[21:28] <hatch> jujugui looking for two reviews and qas on the fullscreen code removal branch (1242ln diff)
[21:29] <hatch> 99% removals
[21:29] <Makyo> hatch, on it \o/
[21:29] <hatch> thank yas!
[21:29] <Makyo> Have a PR?
[21:29] <hatch> oops
[21:29] <hatch> https://github.com/juju/juju-gui/pull/15
[21:29] <hatch> :)
[21:29] <hatch> forgot to paste
[21:30] <gary_poster> will look soon after bug triage, if no one else has taken
[21:39] <gary_poster> hatch, still triaging, but 1,173 deletions: awesome :-)
[21:39] <hatch> yeah, that was a lot of code haha
[21:39] <hatch> the paths are still overly complex but we can now work on simplifying them 
[21:40] <gary_poster> cool
[21:40] <gary_poster> Makyo, in a shocking move, I accepted your Christmas holiday vacation request
[21:41] <hatch> lol
[21:41] <gary_poster> thanks for filing :-)
[21:41] <Makyo> !!!
[21:41] <Makyo> Thanks :_
[21:41] <Makyo> :)
[21:41] <hatch> what we get Christmas holidays? 
[21:41] <hatch> NO WAY!
[21:41] <Makyo> I needed to see how many days would roll over for the convention trip in January.
[21:41] <hatch> oh what convention?
[21:42] <rick_h__> hatch: howdy
[21:42] <Makyo> Sci-fi/furry :P  Giving a talk on data collection and visualization.
[21:43] <hatch> http://www.scififur.net/forum/forum.php ?
[21:43] <Makyo> http://www.furtherconfusion.org/2014/
[21:44] <hatch> coolio, are you dressing up?
[21:45] <Makyo> At some point, sure, but not during the talk.  Too much to deal with.
[21:47] <Makyo> Want to tool around the bay area a bit, too, eat at all the neat places we don't have here in town.  I know it's basically fast food there, but we don't have any ramen shops here :T
[21:47] <hatch> haha - I buy ramen in dry plastic wrapped cubes
[21:47] <hatch> aka ichiban!
[21:47] <hatch> lol
[21:48] <Makyo> Pff!  I do too, but after going to a few real ramen places out there, I'm hooked on that.
[21:48] <hatch> we are starting to get a lot of 'foodie' type restaurants here but none really have the level of quality i've come to expect from places on my travels which is unfortunate
[21:49] <Makyo> Yeah, for sure.  There are a few cropping up in town, thankfully, but some stuff is underrepresented.  Korean food, notably: we have a pretty big Korean population, but the restaurant that's owned by a Korean family mostly just serves sushi.
[21:50] <hatch> that's...odd...heh
[21:56] <hatch> you can tell the best asian restaurants here really easily
[21:56] <hatch> if they are full of white people, it's probably not very good :D
[21:56] <hatch> it's like "ohh this is WESTERN Chinese food"
[21:56] <hatch> haha
[21:58] <Makyo> There's a place here that helps with work visas for people, so their food is amazing.
[21:59] <Makyo> It's pretty cool, from what I've heard.  They help a family with work visas, find housing, and so on.
[22:01] <rick_h__> man hatch you're killing me. Realizing just how much code and tests went into making fullscreen happen. 
[22:01] <hatch> rick_h__ yeah only like 1200 lines worth :P
[22:01] <rick_h__> is that what the diff is? ugh
[22:02] <rick_h__> I'm happy to see it go, but painful as well
[22:02] <hatch> haha yeah, sorry :) but I must admit, it was was easy to remove
[22:02] <hatch> so you did a good job modularizing everything
[22:02] <rick_h__> :)
[22:02] <gary_poster> rick_h__, when you get a chance, could you comment as to whether you think https://bugs.launchpad.net/juju-gui/+bug/1259704 should be addressed in charmworld or gui?  If gui, would like to ask huw to fix it quickly.
[22:02] <_mup_> Bug #1259704: Bundle branch command incorrect. <juju-gui:Triaged> <https://launchpad.net/bugs/1259704>
[22:02] <rick_h__> gary_poster: rgr
[22:02] <gary_poster> rick_h__, thank you (tomorrow is great!)
[22:02] <gary_poster> hatch, I won't be reviewing; have to go
[22:03] <gary_poster> bye all
[22:03] <rick_h__> have fun
[22:03] <hatch> gary_poster no problem, cya
[22:05] <Makyo> hatch, code's good, going to walk dogs then QA
[22:05] <hatch> great thanks
[22:12] <hatch> morning huw
[22:12] <huwshimi> Mornign
[22:12] <huwshimi> *Morning
[22:33] <rick_h__> hatch: the reroute or something is breaking onboarding
[22:34] <hatch> rick_h__ repro steps?
[22:34] <rick_h__> hatch: clear your localStorage, go to /
[22:34] <rick_h__> hatch: to see it work, clear your localStorage go to /sidebar
[22:34] <rick_h__> hatch: this is in trunk, not your branch atm
[22:34] <hatch> ohh ok 
[22:34] <hatch> so a separate card then
[22:34] <rick_h__> hatch: I'm guessing it's part of the redirect/etc work
[22:35] <hatch> nice catch though, I never thought of checking that
[22:35] <rick_h__> hatch: can you duplicate? I was going to check comingsoon but that's not updating off of git trunk atm
[22:35] <hatch> checking
[22:37] <hatch> rick_h__ what was the chrome command to clear localstorage?
[22:37] <hatch>  I just always did localStorage.clear()
[22:37] <hatch> but I want to make sure it's out of the list
[22:37] <hatch> but my google fu is failing me
[22:38] <hatch> rick_h__ I can confirm
[22:38] <hatch> definitely a bug
[22:38] <rick_h__> hatch: oh sorry, I go to the resources tab in dev tools and look at the list
[22:38] <rick_h__> then click/delete the itmes
[22:39] <hatch> yup it's definitely broken
[22:39] <hatch> localStorage.clear() does work too, which is pretty cool :)
[22:40] <rick_h__> hatch: k, I'll file a bug/add a card for it
[22:49] <rick_h__> hatch: posted QA issues
[22:49] <rick_h__> hatch: some of them might be related so will hold off on more QA until tomorrow and will go through it again
[22:49] <hatch> rick_h__ do you think these happen on trunk too
[22:50] <hatch> as part of the redirect not the code removal?
[22:50] <rick_h__> hatch: no, some are pure fullscreen
[22:50] <rick_h__> the sidebar issue might, not sure. 
[22:50] <hatch> well I mean there is no /fullscreen as far as the code is concerned
[22:50] <hatch> it gets redirected
[22:50] <hatch> and never touches the other code
[22:50] <rick_h__> hatch: right, but it's not redirecting cleanly
[22:50] <hatch> right, so these issues should happen on trunk?
[22:50] <rick_h__> some of the urls are possible user bookmarked urls that need to map cleanly
[22:51] <rick_h__> hatch: ah, ic 
[22:51] <hatch> the search results one is interesting though
[22:51] <hatch> will look into that
[22:51] <rick_h__> heh, they're worse on trunk as you don't even get a sidebar at all
[22:52] <rick_h__> you just get the canvas sans-browser
[22:52] <hatch> eek
[22:52] <rick_h__> hatch: yea, I think the redirect should detect the requested viewmode and rather than just navigate, change the viewmode and do a browser viewNavigate so that the rest of the viewstate is kept in place
[22:53] <hatch> I can reproduce your sidebar issue, so I'll take a deeper look into that
[22:53] <hatch> and maybe at the same time try and fix the redirect stuff
[22:53] <rick_h__> the sidebar issue is on trunk as well
[22:53] <hatch> oh? hmm
[22:53] <hatch> maybe land as is then and roll another branch?
[22:53] <rick_h__> hatch: so maybe that's fallout from sticky headers?
[22:54] <rick_h__> well, I think it kind of sucks to keep going removing fullscreen (and hints on what's changed) with the broken url/search/state stuff
[22:54] <hatch> my guess is it's fallout from the browse/build removal stuff
[22:54] <rick_h__> I know your branch isn't 100% at fault, but it's related and think those urls should 'work' as part of removing this stuff
[22:54] <hatch> yeah that's true
[22:54] <hatch> ok I'll look into it
[22:54] <rick_h__> thanks