Upgrading to 1.6.0

[treybean]

Hi,

I'm upgrading an app from modalbox 1.4 to 1.6. Everything seems to be
working except on one of my pages, everytime modalbox is called, the
modalbox appears, seems to be loading and then closes without any sort
of error. I've used firebug to verify that the content is being
returned correctly from the get request. I just can't figure out why
the window is closing.

Any ideas?

Trey

[treybean]

Okay, further information about the mysterious closing modalboxes:

Using firebug to issue javascript pages.

If I run Modalbox.show('/events/60');, the modalbox appears briefly,
sometimes I can even make out the content, and then it closes without
error.

I check firebug to see what was returned:
<div class="event_details">
<h3>Test</h3>
<h5>12/18/2007</h5>
<h6>Time:</h6>

<p class="start">Doors open @ 12:00 AM</p>
<a href="">Go to artist's site</a>
</div>

<div class="event_description">
<p class="description"><p>Test</p></p>
</div>

If I take that and try to enter that directly in the modalbox call
like so
Modalbox.show('<div class=\"event_details\"><h3>Test</
h3><h5>12/18/2007</h5><h6>Time:</h6><p class=\"start\">Doors open @
12:00 AM</p><a href=\"\">Go to artist\'s site</a></div><div class=
\"event_description\"><p class=\"description\"><p>Test</p></p></div>')

This opens up correctly and stays open.

Can anyone think of something that would be causing my modalbox to
close automatically without error in the first case? I've also
confirmed that it isn't just on this one page, but on others as well.

Thanks,
Trey

[Andrey Okonetchnikov]

Hey,

this one seems very strange to me. The modalbox could hide
automatically in case of errors (wrong parameters or wrong ajax try
out) but the error should be thrown to the console. It doesn't seems
to be your case... Could you please open this page to the public so I
could take a look into it?

Andrey

--
With best regards,
Andrey Okonetchnikov

[treybean]

Okay, http://treyanderin.dsl.xmission.com:3000/calendar

There will be a link on 12/18 that says 'Test'; clicking that fires
the modalbox.

When I was testing that I had successfully opened up this port, I
tried it on a windows machine and it threw a javascript error:
Exception thrown but not caught.

any help on this will be appreciated. I'll post if I figure anything
out in the meantime.

Cheers,
Trey

On Dec 19, 11:45 am, "Andrey Okonetchnikov"

<andrej.okonetschni...@gmail.com> wrote:
> Hey,
>
> this one seems very strange to me. The modalbox could hide
> automatically in case of errors (wrong parameters or wrong ajax try
> out) but the error should be thrown to the console. It doesn't seems
> to be your case... Could you please open this page to the public so I
> could take a look into it?
>
> Andrey
>

[treybean]

Okay, I also realized I might also want to pass on that using firebug,
if I issue the commands:

Modalbox.show('/contact_us') or Modalbox.show('/tickets') --other pages
on the site--, the modalbox stays open like it's supposed to.

Hmmm

On Dec 19, 12:35 pm, treybean <treyb...@gmail.com> wrote:
> Okay,http://treyanderin.dsl.xmission.com:3000/calendar

[Andrey Okonetchnikov]

Hey, here lies your problem: calendar.js which is supposed to handle
all links via location (not sure this is good either). There is no
parameter height: 'auto' for Modalbox. The height should be integer.
Just remove it everywhere. When not specified Modalbox will operate in
automatic mode.

Andrey

[treybean]

I just tried removing the height as well as commenting out the
function in calendar.js, but we're still having problems. Any other
ideas?



On Dec 19, 12:58 pm, "Andrey Okonetchnikov"

<andrej.okonetschni...@gmail.com> wrote:
> Hey, here lies your problem: calendar.js which is supposed to handle
> all links via location (not sure this is good either). There is no
> parameter height: 'auto' for Modalbox. The height should be integer.
> Just remove it everywhere. When not specified Modalbox will operate in
> automatic mode.
>
> Andrey
>

[Andrey Okonetchnikov]

Yeah, seems I went wrong with the previous suggestion. Digging into it now.

Can you deploy the code with 'height' option being not set?

Andrey

[treybean]

It shouldn't be being set now, at least on that 'Test' link.

On Dec 19, 1:08 pm, "Andrey Okonetchnikov"

<andrej.okonetschni...@gmail.com> wrote:
> Yeah, seems I went wrong with the previous suggestion. Digging into it now.
>
> Can you deploy the code with 'height' option being not set?
>
> Andrey
>

[Andrey Okonetchnikov]

Just a guess but give it a try. I noticed that then calling
'/events/60' the headers for the page is 'text/javascript' not
'text/html'. Try modify headers to 'text/html' for these pages.

Andrey

[Jesse Dhillon]

Works for me in Firefox.

Jesse.

[treybean]

Well, that did it. But I don't know how much I like the solution.
This is a rails project and by default, rails checks the request
headers to try and figure out how to respond. Since this is an AJAX
call, it has the request accept header set to text/javascript, text/
html, application/xml, text/xml, */*. Rails in turn responds with
text/javascript.

In the app, if it's a javascript call, it actually doesn't return
javascript and instead html, so maybe this will work. I don't know.
It could be a stumbling block for others though. Are you doing
anything with the content-type in the modalbox code?

Trey

On Dec 19, 1:14 pm, "Andrey Okonetchnikov"

<andrej.okonetschni...@gmail.com> wrote:
> Just a guess but give it a try. I noticed that then calling
> '/events/60' the headers for the page is 'text/javascript' not
> 'text/html'. Try modify headers to 'text/html' for these pages.
>
> Andrey
>

[Andrey Okonetchnikov]

Nope, I do nothing with the conten-type but prototype does I guess.
Then it comes to insert content Modalbox evaluates inline javascript
which came with the request. I'm using prototype's method to eval
these scripts and it seems problem appear in that place.

From the other hand the fix you did is okay since you're requesting
for HTML content, not javascript. I thought you were using partial
rendering. Either way this part of the code is far from new and I
never heard about this kind of problem before.

I'll consult with our Rail developer anyway.

Andrey

[treybean]

I think that if the response's content-type has to be text/html, then
you should set the accept request header on the Ajax.request call in
loadContent. Ajax.Request defaults Accept to 'text/javascript, text/
html, application/xml, text/xml, */*'. For rails, this tells it to
respond with javascript. Admittedly, I shouldn't be sending back html
when the request want javascript, but this is how I got it to work in
1.4. With it not working in 1.6, I'll definitely switch it around so
that it behaves correctly in my app, but it would help if the modalbox
call was asking for the correct content-type.

Thanks for helping figure this one out. I love this little library.
Great work!

Trey

On Dec 19, 1:42 pm, "Andrey Okonetchnikov"

<andrej.okonetschni...@gmail.com> wrote:
> Nope, I do nothing with the conten-type but prototype does I guess.
> Then it comes to insert content Modalbox evaluates inline javascript
> which came with the request. I'm using prototype's method to eval
> these scripts and it seems problem appear in that place.
>
> From the other hand the fix you did is okay since you're requesting
> for HTML content, not javascript. I thought you were using partial
> rendering. Either way this part of the code is far from new and I
> never heard about this kind of problem before.
>
> I'll consult with our Rail developer anyway.
>
> Andrey
>

[Andrey Okonetchnikov]

Hmm, sounds interesting. I'll definitively dig into this problem.
Thanks for you patience.

Andrey

[Chris]

I was also having the same problem with a rails app. Just for the
record this affected IE and also Safari (on OS X) but didn't seem to
bother Firefox at all.

On Dec 19 2007, 10:26 pm, "Andrey Okonetchnikov"

<andrej.okonetschni...@gmail.com> wrote:
> Hmm, sounds interesting. I'll definitively dig into this problem.
> Thanks for you patience.
>
> Andrey
>

[Josh]

I'm having the same problem. I added headers['content-type'] = 'text/
html' to the action that renders the content for the box and it worked
in Safari, but still not in IE :(

@treybean: Is that how you set the headers to get it to work or is
there something I am missing?

[treybean]

Hi Josh.

I just changed line 243 in the load_content method to the following:

new Ajax.Request( this.content, { method:
this.options.method.toLowerCase(), requestHeaders: ['Accept', 'text/
html, application/xml, text/xml, */*'], parameters:
this.options.params,

basically, I added the requestHeaders part to add the Accept header.
Let me know if you have any problems getting this to work.

Trey