Hi Ben,

Could you confirm this popup window resizing issue is only relating to
Win7 only?

On May 6, 2:01 pm, Ben Ward <benw...@twitter.com> wrote:
> Hi Corey,
> Thanks for your feedback.
> On May 5, 2011, at 8:15 AM, Corey Ballou wrote:
> > Your new OAuth authentication handler does a check to determine if the
> > window has been opened in a new window and triggers a resize.
> > I'll preface this message by saying that I have a high res monitor at
> > 1920x1600. I currently have handling to center the window. Your new
> > JavaScript is essentially resizing the window outside of the viewport,
> > giving no consideration to the end user's window height or current
> > window position.
> > Is this something that can be resolved? It's kind of a nuisance. I'll
> > repost in the tracker.
> The auto-resize is not something I'm a massive fan of either, but we 
> implemented it after the redesign because we found that whilst a lot of OAuth 
> implementations are using pop-ups of a fixed sized, a great number of them 
> are also invoking those pop-ups with scrollbars disabled at the window level, 
> which makes important parts of the interface impossible for users to access.
> Alas, though I appreciate that centering the window is aesthetically 
> desirable, content hidden through disabled scrollbars was a bigger problem, 
> so it's been patched for now.
> I emphasise ‘for now’ because I know and agree that this isn't an ideal 
> solution. Web content is by its nature of variable length. In this case:
>   • Additional status messages can be displayed in the content. The 
> authenticate flow has an extra header message, and users adding their first 
> app are also given a special greeting message, and offered a link to the help 
> section to explain what apps are.
>   • Items on the page, and in the permission list may be changed, shortened, 
> lengthened or removed outright based on feedback and experience. And, of 
> course, Twitter will add new features over time, or might redesign the site 
> again some day.
> These are all changes that developers should expect to happen to every web 
> service, not just Twitter, and should code for defensively. What's more, 
> users can, will, and do use browser features such as resizing page text based 
> on their needs, which throws all page size expectations out of the window. 
> Given all of this, it mystifies me slightly that browsers allow scrollbars to 
> be disabled at all, but here we are.
> I'm keen that we assemble issues like this into a best practices guide. Not 
> disabling scrollbars, and keeping the address bar (and SSL verification 
> stamps) visible are important. There's more too, and I'd like to collect the 
> feedback and experience of developers to help assemble thorough and relevant 
> advice. (Please write in to the usual address.) (This one.)
> My hope and preference is that after documenting these issues and encouraging 
> their adoption, we can remove the janky resize code and return all pop-up 
> size and shape related issues entirely to the domain of the app developer.
> Thanks,
> Ben
> --
> @benward

Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 

Reply via email to