Loading taking too long

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Log in to the admin
2. View an edit form for a model

Using the latest stable. Django 1.3 alpha 2. Chrome dev.

Page loads fine, but it takes about 2s to actually render the page. I see a 
white page in the meantime. It renders the app barely usable. 

Is that a known issue or am I doing something wrong?

Original issue reported on code.google.com by pokorny....@gmail.com on 4 Mar 2011 at 6:28

[GoogleCodeExporter]

question is, how long does it take without grappelli?
how did you analyze the 2 seconds? firebug? anything else?

2s doesn´t really scare me btw.

Original comment by sehmaschine on 5 Mar 2011 at 12:46

[GoogleCodeExporter]

Thanks for getting back to me. 

Without Grappelli, the page loads just fine. Nothing unusual there. The 2 
seconds were just a perceived length of time, I didn't measure it. 

With Grappelli, the page loads in 1.16s, but most of the elements are hidden. 
It takes about 2-3s for them to appear. It can't be measured with firebug and 
the like. 

Here is a video of what I'm talking about. Notice that the page is loaded and 
then there is a wait.

http://dl.dropbox.com/u/7102514/grappelli.mov

Original comment by pokorny....@gmail.com on 5 Mar 2011 at 7:26

[GoogleCodeExporter]

Just upgraded django and grappelli to trunk. Still getting the same thing. I 
also discovered that clicking anywhere on the page will show stuff faster. But 
how will my users know to do that? 

Original comment by pokorny....@gmail.com on 5 Mar 2011 at 8:05

[GoogleCodeExporter]

Additional information: I just tested this in Firefox and it works perfectly. 
It looks like a JS/CSS issue with Chrome (dev). Thanks!

Original comment by pokorny....@gmail.com on 6 Mar 2011 at 12:24

[GoogleCodeExporter]

that looks strange indeed ...
do you see any 404s – like tinymce not loading or something else?
I just tested with chrome and it´s even faster than firefox.

can you test with chrome and djangos user-model? because than we´re talking 
about the same model and that´s probably easier.

Original comment by sehmaschine on 6 Mar 2011 at 11:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I tested it with the User model and I'm getting the same thing. No difference.

There are no 404s, but I did get a warning in the webkit inspector: line 252 - 
parse error (recovered gracefully) on /admin/auth/user/1/. 

I also noticed that clicking the page is the only way to display the content. 
No matter how long I wait, it never shows. I apologize for a poor analysis 
earlier. I doesn't take a long time to show. It never shows unless I click 
anywhere. 

Does that make sense?

Thanks!

Original comment by pokorny....@gmail.com on 6 Mar 2011 at 5:52

[GoogleCodeExporter]

hard to say what´s going on since I´m not able to reproduce it. it looks like 
a js-error but it´s obviously not (since you checked that). 

what else (besides grappelli) did you install? can you please send your 
INSTALLED_APPS, the middleware-settings and the context-processors?

Original comment by sehmaschine on 6 Mar 2011 at 6:03

[GoogleCodeExporter]

Here is my entire project. I followed the quick start guide. And I added a 
super simple app called blog. 

Original comment by pokorny....@gmail.com on 6 Mar 2011 at 6:15

Attachments:

• grappelli-debug.zip

[GoogleCodeExporter]

@pokorny: It's a strange problem and I'm not able to reproduce it.
Since you wrote in comment 8 that you have to click the page to see the content 
and your video shows that you get the H1 it must be a problem with the 
container-flexible.

I would ask you to play with the following css (as it makes no difference in my 
Chrome):

structures.css, line 438: please try to modify all parameters, especially the 
float. Maybe add a display: block;
.container-flexible {
    clear: both;
    float: none;
    height: 100%;
    position: relative;
    width: auto;
}

thanks, axel

Original comment by parsch.inc@gmail.com on 9 Mar 2011 at 5:22

[GoogleCodeExporter]

@pokorny: does the problem still exist?

Original comment by sehmaschine on 17 Mar 2011 at 4:28

[GoogleCodeExporter]

Sorry about the delay. I will verify and send another reply.

Original comment by pokorny....@gmail.com on 17 Mar 2011 at 4:30

[GoogleCodeExporter]

should be solve with r1430, please verify

Original comment by parsch.inc@gmail.com on 3 May 2011 at 5:20

[GoogleCodeExporter]

Hi

I'm not sure if it's the same problem. I have model with four m2m fields (there 
are also other fields) and there is quite big amount of data displayed in them 
(up to few thousand in one m2m). Everything works fine in admin if I define 
'filter_horizontal' option for m2m fields or 'fieldsets'. Problem occures when 
booth options are used. Then on Chrome admin edit page loads very long and 
finally hangs. I don't see any js bugs. On Firefox 4 everything seems to work 
properly.

I use Django 1.3, latest Grappelli r1431, Chrome 11.0.696.57

Original comment by szc...@gmail.com on 15 May 2011 at 8:21

[GoogleCodeExporter]

no, that´s another issue ... but I´m pretty sure it´s not related to 
grappelli. moreover, I guess it´s not a good idea to use "filter horizontal" 
for thousonds of options (use a raw-id-field instead).

Original comment by sehmaschine on 21 May 2011 at 8:33

[GoogleCodeExporter]

I use Chrome as my default browser and Grappelli in all of my Django projects. 
I have this issue in every project. For me, it's not that things take long to 
load, they are there but will not appear until I click on the screen. It 
happens in Chrome on Windows (XP and Windows 7) and Mac. It happens locally and 
on remote servers. It does not happen in Safari, so it's not a WebKit issue, 
just a Chrome one. It happens on all screens in the admin, login, listing 
pages, edit forms.

Original comment by tcla...@gmail.com on 27 May 2011 at 3:45

[GoogleCodeExporter]

Ah, duh, why don't I read all the comments. r1430 fixed the issue. Thanks so 
much!

Original comment by tcla...@gmail.com on 27 May 2011 at 3:48

[GoogleCodeExporter]

closing this issue as it seems to be solved.

Original comment by sehmaschine on 28 May 2011 at 9:55

• Changed state: Fixed