[Interest] bug with # in URL when using setUrl?

[Larry Martell]

On Tue, Mar 15, 2016 at 9:14 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On terça-feira, 15 de março de 2016 19:15:03 PDT Larry Martell wrote:
>> So that led me to these questions:
>>
>> -What runs the JS code on the client?
>
> JavaScriptCore, WebKit's JS engine.

Is that part of Qt? I googled it, and it seems it's something that
comes with Mac's, but does it also come with Qt?

I've done some more testing on 5 different machines - 4 Mac's and 1
Windows. Unfortuanly no patterns emerged that I can draw any
conclusions from:

2 macs, both running Mavericks  where Qt was built from source and it
works on those
1 Windows, running 8, where Qt was built from source and it doesn't work there
1 mac running Mavericks that has the downloaded Qt libs installed and
it doesn't work there
1 mac running Mountain Lion that is running the packaged app from a
dmg file and it doesn't work there

>> -Is there a cache for the JS code and is it the case that 8000/# will
>> only actually go out on the wire if the routeProvider code is not
>> present on the client?
>
> No cache.

Interesting. So I'm wondering why I don't see the 8000/# request go
out on the wire.

>> -How can I debug the Angular code?
>
> No idea. That's not a Qt question. It's entirely possible that the AngularJS
> code is at fault here, doing some User-Agent matching (I don't know whether
> you set an UA or whether the default QtWebKit UA differs from platform to
> platform).

So if the OS comes with a JavaScriptCore would it use that or the Qt
one? Any how do I find out what version each platform has?

> What I'd make sure is that the DOM window.location is the same in all
> platforms given the same input URL. If that's the same, try to trigger the
> same requests that you saw in a working environment, using the same JS
> functions (XML HTTP Requests, whatever).

Thanks for the pointers!