Edgewall Software
Modify

Opened 19 years ago

Closed 18 years ago

Last modified 8 years ago

#1969 closed defect (worksforme)

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

Reported by: lzap@… Owned by: Jonas Borgström
Priority: normal Milestone:
Component: ticket system Version:
Severity: major Keywords:
Cc: lzap@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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).

Attachments (0)

Change History (29)

comment:1 by anonymous, 19 years ago

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?

comment:2 by Christopher Lenz, 19 years ago

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

comment:3 by Matthew Good, 19 years ago

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.

comment:4 by Christopher Lenz, 19 years ago

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.

comment:5 by Christian Boos, 19 years ago

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.

comment:6 by lzap@…, 18 years ago

Version: 0.8.10.8.2

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.

comment:7 by anonymous, 18 years ago

Version: 0.8.20.9.2

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…

comment:8 by anonymous, 18 years ago

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.

comment:9 by anonymous, 18 years ago

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">…)

comment:10 by anonymous, 18 years ago

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 :-(

comment:11 by Christopher Lenz, 18 years ago

#2552 has been marked as duplicate of this ticket.

comment:12 by romanr, 18 years ago

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.

comment:13 by Christian Boos, 18 years ago

Milestone: 0.9.4

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

comment:14 by markus, 18 years ago

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)

comment:15 by Christopher Lenz, 18 years ago

Milestone: 0.9.40.10

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

comment:16 by anonymous, 18 years ago

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?

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:17 by anonymous, 18 years ago

Cc: lzap@… added

comment:18 by Christopher Lenz, 18 years ago

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

  /ticket/19 -> POST -> /ticket/19#preview
Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:19 by anonymous, 18 years ago

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.

comment:20 by anonymous, 18 years ago

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…

comment:21 by anonymous, 18 years ago

Version: 0.9.2

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.

comment:22 by Matthew Good, 18 years ago

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.

comment:23 by anonymous, 18 years ago

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.

comment:24 by lzap, 18 years ago

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

comment:25 by anonymous, 18 years ago

Still a problem in the beta?

comment:26 by anonymous, 18 years ago

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

comment:27 by Matthew Good, 18 years ago

Milestone: 0.10
Resolution: worksforme
Status: newclosed

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

comment:28 by Christopher Lenz, 18 years ago

#3222 marked as duplicate of this ticket.

in reply to:  3 comment:30 by samuli.seppanen, 12 years ago

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.