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: http://groups.google.com/group/twitter-development-talk
