World: r3wp

take/part 373

Thanks. 235 is all of the current stuff - the "worst severity" is 
a sorting criterium.

I just wanted to test that bug again, but forgot the number. I wonder 
if the View Tickets not working for me is permissions-related.

I reported the same problems already. Just restart your browser.

That will take a while - I have too many pages open that I haven't 
read yet.

don't most browsers have option "save all tabs before closing" ?

Just Firefox, which uses too much ram for a netbook. I have to use 
Chrome (actually Chromium).

See my numerous posts about the subject in Qtask :(

I get this with FF with all sites sometimes.

That is rather strange claim, Brian? How much RAM does your netbook 
have? Those have at least 512 or more RAM, which should be pretty 
much sufficient for FF?

A netbook with an SSD can't use a swap file, so 1GB of ram is *all* 
you get. If I use Firefox I have to close almost all other programs.

ah, I remember the days I could browse the web on my Amiga 4000 with 
just 16 MB RAM... :-)

The web has changed since then (though CureCode would have fit in 
just fine with the web of that time).

I hope we can change it back again with ReBrowser. Probably not entirely, 
but I would love to see Curecode/QTask clients for ReBrowser.

Absolutely :)

Rebooting my browser (and upgrading it while I was at it) solved 
the problem. Thanks, Rebolek :)

And sqlab :)

Btw, "Worst Severity" includes built and dismissed tickets, which 
throws off the total. It should probably not include dismissed at 
least.

Cheyenne server upgraded to latest version. It should fix the "corrupted 
session" issue reported by sqlab and BrianH. Let me know if you see 
regressions.

Cheyenne server upgraded again. The new on-the-fly RSP output compression 
should make RSP pages loading 2x faster on average than before (but 
you may not noticed as CC pages load already very fast)

Is there much overhead compressing them before sending?

Sorry, Cheyenne question...

Answering in Cheyenne...

Getting the redirect loop on edit bug again. Clicking on a ticket 
from the View Tickets list takes me to:
- http://curecode.org/rebol3/edit-ticket.rsp?id=607&cursor=1
which takes me to

- http://curecode.org/rebol3/set-project.rsp?prj-id=2&ref=edit-ticket.rsp%3Fid%3D607%26cursor%3D1
and back again, endlessly.

That last line was "and back again, endlessly."

How do I reproduce that issue? I've tried using the admin account, 
but reproduce it.

but <can't> reproduce it

I am using Chrome. I login then click on the ticket link. That's 
it. It even works when I set the project in the project dropdown 
before I click the link. If I don't log in and go directly to View 
Tickets, clicking on the link takes me to ticket.rsp page with the 
same redirect loop. When the bug happens, it happens every time.

Doesn't happen with IE7.

The problem isn't there most days - this is not one of those days.

Could you try clear your cookies cache to see if it fix the issue?

Ok, reproduced with Chrome.

Works Ok with IE7 and FF. Looks like Chrome is more sensible on multiple 
redirections.

I don't like to clear the cookies an my primary browser - I end up 
having to log into a ton of sites. I can't clear just one site's 
cookies.

an -> on

You don't have anymore, it looks like it's not related to old session 
cookie afterall. At least one ticket is opened in Chrome's tracker, 
but not confirmed by developers: http://code.google.com/p/chromium/issues/detail?id=1267

...have <to> anymore...

Cheap workaround, go to the second result ticket, then use the Previous 
[<] button.

I'll see how I can avoid the extra redirection for the first ticket 
in the next release.

[Logout] link doesn't seem to work with Chrome too.

I'll try upgrading to a new nightly Chromium build and see if that 
helps.

From a design POV, Chrome is right, web servers shouldn't redirect 
twice for a given resource, but, sometimes, it really helps by reducing 
complexity and code size.

The problem is not the twice, it's that it keeps going. I do the 
reload to let it continue and it does, back and forth forever.

Strange, if you keep clicking on the [refresh] link, it loops endlessly, 
but if you click inside the address bar and hit Enter key, it works.

Looks like a Chrome bug.

Anyway, CC shoudn't redirect twice, that's bad design.

Great, I "upgraded" Chromium and now autocomplete doesn't work (anywhere), 
in addition to the redirect bug still being there. :(

I'll have to try upgrading it again tomorrow.

Figured out which build I used to have and am reverting now. I'll 
keep a copy of its installer, just in case.

Logout works for me though.