Bug 314743

Comment 1 Rüdiger Herrmann 2010-05-27 14:28:32 EDT

It aint that easy as it seems. setText() has different semantics than the private method you are referring to.

Comment 2 Benjamin Muskalla 2010-08-11 22:41:04 EDT

*** Bug 322461 has been marked as a duplicate of this bug. ***

Comment 3 Elias Volanakis 2010-08-11 22:46:40 EDT

:-)

Comment 4 Miles Parker 2011-01-13 15:06:07 EST

(In reply to comment #0)
> Browser has #setText() but no #getText(). Please add post 1.3. 
> 
> ( Current workaround: using reflection to read private String html field )

I don't think that will work, because the adapters private html doesn't have the content either. I tried getting it from BrowserAdapter, but no dice.

Comment 5 Ralf Sternberg 2011-01-13 15:46:37 EST

I think pushing the content back from client to server would not work a) due to cross-domain restrictions b) because it would be overkill to pass any content to the server just in case it's needed later.

So the only way to get hold of the content would be by proxying it through the server. This seems tempting, as we'd get rid of any cross-domain issues with browser functions wouldn't we? But this would require the RAP server to have web access, and I'm afraid we can't involve this requirement just for this one function.

For me, this request seems almost impossible. Others?

Comment 6 Miles Parker 2011-01-13 16:40:44 EST

(In reply to comment #5)
> I think pushing the content back from client to server would not work a) due to
> cross-domain restrictions b) because it would be overkill to pass any content
> to the server just in case it's needed later.

I'd take an optional b) if it were possible to get a) working. :)

> So the only way to get hold of the content would be by proxying it through the
> server. This seems tempting, as we'd get rid of any cross-domain issues with
> browser functions wouldn't we? But this would require the RAP server to have
> web access, and I'm afraid we can't involve this requirement just for this one
> function.

Yes, I was thinking of doing it on server-side. It wouldn't be too hard, I guess. But that wouldn't work for my very specialized use case as that involves pretending to be a user to get around certain (ahem) public APIs discovery of source browser in order to prevent bot access so I need to be a user browser anyway. We certainly wouldn't want to create a UI user session on the server. :D 

> For me, this request seems almost impossible. Others?

I dunno as browser security is well outside of my expertise, but couldn't it be obtained from current user context. OTOH, I guess a good way to think about this sort of stuff is "what could a malicious developer do *if* they were able to accomplish this?" From that perspective, being able to publish a URL request on "behalf" of the user (i.e. using their cookies, logins, etc..) and then being able to get the results of that request seems a wee bit sketchy from a privacy/security POV. Perhaps we should stop that speculation here. :D

Comment 7 Ivan Furnadjiev 2012-04-05 04:26:54 EDT

(In reply to comment #5)
> For me, this request seems almost impossible. Others?
I think that this request is impossible to implement too. Will close it as WONTFIX.