Browser is waiting for 5-20 seconds when editing a ticket

[lzap@…]

When I create or edit a ticket, my browser is waiting for response for a long time. All other pages, including editing WIKI pages, are quick-replied.

I tried either CGI or mod_python version.

Using Gentoo GNU/Linux with latest Apache/Python packages (stable in Gentoo).

[anonymous]

I need to point that when I check the tickets in other window while the browser is still waiting, the ticked is already created/edited. Strange, huh?

[Christopher Lenz]

What browser are you using? Does the response eventually arrive (i.e. get rendered)?

[Matthew Good]

This is most likely due to email notification. If you've turned on email notification and have the server settings wrong it may hang while trying to send the emails.

[Christopher Lenz]

I've also heard of a problem in Opera that doesn't seem to like the redirect we make after ticket submission. That's an Opera bug however, IMHO.

[Christian Boos]

Saving a comment on #1968 just demonstrated this problem for me. I have Firefox 1.0.6 on Windows. The page came OK after 20 seconds or so.

[lzap@…]

This happens in either Firefox or Opera (on Linux). The page seems to be re-rendered, but the browser waits for anything… And the new comment is not there.

[anonymous]

The same problem on this Trac too (youre using latest stable, isnt it?).

The HTML seems to be downloaded already (I can see it using "Show Source" function - theres my new comment there), but the browser is waiting for something. For what?

The Preview is always OK. Only the Sumbit Changes do this…

[anonymous]

When I do "Preview" and then "Submit Changes", its ok. When I hit "Submit" without it, theres this bug. Please let me know, if I can help, I really want to have this issue fixed.

[anonymous]

I think there is a problem with the HTML archors. The FORM gets rendered to something#preview, but there is no #preview archor. This is maybe the problem. It needs to be #change_X, where X is the latest number, but this solution is not good - its not client-safe (any1 can add new comment and the archor should be N+1).

I suggest to create a "static" #preview archor which will be rendered on every page. Now the preview archor is only generated, when Preview button is pressed (…<fieldset id="preview">…)

[anonymous]

This happens only in comments. New ticket is ok or comment with preview is ok too (see above). Sorry for so many comments, trying to solve it… Maybe this is some redirect problem, cannot see any redirect headers in the HTML :-(

[Christopher Lenz]

#2552 has been marked as duplicate of this ticket.

[romanr]

Clean install, single user is using Trac. 9 of 10 times Submitting the ticket page is stuck. Browser does not come out of the waiting. Tickets with various comemnts and settigns combinations. Ticket is actually submitted. When Using "Preview" imemdiately before Submit, browser is stuck only in 50% cases. Using Opera and IE.

[Christian Boos]

Hm, I don't think this problem has been solved. Could it be related to #2006? (and could the flush patch also help here?)

[markus]

Could it be related to #2006? (and could the flush patch also help here?)

Don't think so, but should be double-checked by someone who can reproduce this problem… (as for both of the other tickets)

[Christopher Lenz]

As long as we don't know what's causing this problem, we can't fix it, so postponing for now.

[anonymous]

I think I have found the problem. Opera has a problem with handling the POST of the form:

   <form action="/projects/josephine#preview" method="post">

I tried to monitor the HTTP connections with a HTTP monitor. The problem is, when you create a new ticket, the browser "thinks" it is in the same directory:

 /projects/josephine/newticket -> POST -> /projects/josephine#preview

This works, now we try to edit a existing ticket:

 /projects/josephine/ticket/19 -> POST -> /projects/josephine#preview -> STRANGE BEHAVIOUR

Now the POST request comes from the "higher directory". Opera cannot handle this properly.

I understand Trac is using only one place for all POST edits, but is this a good strategy?

[Christopher Lenz]

Since 0.9 Trac uses the ticket URL as the URL for the POST.

  /ticket/19 -> POST -> /ticket/19#preview

[anonymous]

Ah I see, I have older version installed. Strange. My results are useless then. The bug appears on _this_ trac too (which is obviously 0.9.x version) which has this URLs.

I reported this to Opera A.S.A. but I am not sure about some action or response.

[anonymous]

Same in Opera 8.52 and Opera 9 Technology Preview 2 on _this_ and mine trac.

It seems to me that Opera A.S.A. will fix nothing…

[anonymous]

SEND A BUGREPORT!

Please all reporters, send a bug report to Opera A.S.A. We can try to do something at least:

​https://bugs.opera.com/wizard/

What kind of problem is this? *

Other problem

Brief summary of the problem encountered *

Opera do not work with Trac bug reporting system

What URL triggers this bug, if any?

http://projects.edgewall.com/trac/ticket/1969

Describe in 3 steps or more how to reproduce this bug *

1. try to add a comment, press "Submit Comment" (without pressing "Preview" previously)
2. Opera freezes, but the data was sent
3. Refresh the page /trac/ticket/1969

1. What do you expect to happen?

I expect rendered page.

2. What actually happens?

Nothing!

Please send the bugreport, this is only way to fix this. It seems like a bug in the Opera browser.

[Matthew Good]

Referring to this ticket in the Opera bug report would be helpful, but please don't tell people to submit comments on it to test the bug. There is a ​demo Trac environment that would be a better place to test.

[anonymous]

It seems OPERA fixed the problem! I have tested it with latest build (206 - Linux). Can anyone confirm? Latest build can be reached here: ​http://my.opera.com/desktopteam/

The final RELEASE CANDIDATE will be released very soon.

[lzap]

Please confirm (either under Linux or Windows). We can close the bug then.

[anonymous]

Still a problem in the beta?

[anonymous]

Nope (on Linux), it just works. Pleace check out @ Windows & close.

[Matthew Good]

Well, it sounds like Opera's fixed this, so let's go ahead and close it.

[Christopher Lenz]

#3222 marked as duplicate of this ticket.

[samuli.seppanen]

Replying to mgood:

This is most likely due to email notification. If you've turned on email notification and have the server settings wrong it may hang while trying to send the emails.

This hit me also, with Trac 0.11 on Debian Lenny: pressing "Submit" did work, but the browser just hang there, waiting for response from the Trac server. When I fixed a partially broken postfix configuration, the problem was gone.