Hi,
I've been using a WebBrowser control in my Window Phone application to
login into Twitter. Today I noticed that the login/authorization page
format had changed and it is now unusable in a web browser control
that my application displays. The text on the page is squeezed
together, and the page u
I'm having this problem too. My login browser inside the phone app is
now rendered useless, it doesn't even scroll.
On Apr 28, 1:41 pm, Shannon Whitley wrote:
> I was surprised to see a newly formatted oAuth Authenticate Page. The
> new page doesn't account for the scores of oAuth implementation
I've heard this before.
It sounds like all UIWebView, WebBrowser and probably Android's WebView
are blocked. This is definitely a *good* thing for security reasons.
The "workaround" I recommend: launch the actual browser, using a
:// link (something like myapplication://tokenDone) as the
ret
I've heard this before.
It sounds like all UIWebView, WebBrowser and probably Android's WebView
are blocked. This is definitely a *good* thing for security reasons.
The "workaround" I recommend: launch the actual browser, using a
:// link (something like myapplication://tokenDone) as the
ret
Thanks for your response Tom, but I am not sure whether this could be
done on a Windows Phone 7.
The only way to open a regular browser window from a Silverlight app
on the phone(that I know of) is to use
Microsoft.Phone.Tasks.WebBrowserTask and that just opens a webpage.
Would it be possible to b
Yes. But I don't like xAuth :-) (Not that that should be relevant for you)
Anyway, the "Microsoft.Phone.Tasks.WebBrowserTask" is exactly what I
meant. Can you get WM7 to recognize a yourapp:// URL (custom scheme)?
You could have the OAuth login flow redirect back to that page with the
oauth co
On Apr 30, 12:09 pm, Tom van der Woerdt wrote:
> I've heard this before.
>
> It sounds like all UIWebView, WebBrowser and probably Android's WebView
> are blocked. This is definitely a *good* thing for security reasons.
They are not blocked, it's *only* a problem of layout.
> The "workaround" I
Why is it safer Tom?
Safer for who?
Cheers,
Dean
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-talk@googlegroups.com] On Behalf Of Tom van
der Woerdt
Sent: Saturday, April 30, 2011 12:09 PM
To: twitter-development-ta
In an embedded view, the developer can access the content of the website
without the user knowing it (read passwords, usernames, etc). On most
OSes (definitely iOS, WM7 and Android) this is not possible in the
non-embedded (webbrowser) view.
Tom
On 5/1/11 1:02 AM, Dean Collins wrote:
Why i
On 5/1/11 12:47 AM, Matthieu GD wrote:
On Apr 30, 12:09 pm, Tom van der Woerdt wrote:
I've heard this before.
It sounds like all UIWebView, WebBrowser and probably Android's WebView
are blocked. This is definitely a *good* thing for security reasons.
They are not blocked, it's *only* a proble
On Apr 30, 7:13 pm, Tom van der Woerdt wrote:
> On 5/1/11 12:47 AM, Matthieu GD wrote:> On Apr 30, 12:09 pm, Tom van der
> Woerdt wrote:
> >> I've heard this before.
>
> >> It sounds like all UIWebView, WebBrowser and probably Android's WebView
> >> are blocked. This is definitely a *good* thi
Poderia ser possível que o que o Twitter Search analisador não trata
de bem com diacríticos Portugues?
> #UniãoDoTwitterSegueEuTeSigoDeVolta
The Twitter search component was acquired from Summarize a few years
back, and it's been a great piece of tech - but it's alas not very
native and it probab
12 matches
Mail list logo