https://bugzilla.wikimedia.org/show_bug.cgi?id=72909

Florian <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|Unprioritized               |Normal
             Status|UNCONFIRMED                 |ASSIGNED
        Web browser|Apple Safari                |---
           Hardware|Smartphone                  |All
    Mobile Platform|iOS 7.x                     |---
         Depends on|                            |72910
           Assignee|[email protected]. |florian.schmidt.welzow@t-on
                   |org                         |line.de
     Ever confirmed|0                           |1
                 OS|other                       |All

--- Comment #1 from Florian <[email protected]> ---
Actually it depends on MobileFrontend in a special way :) Both Extensions,
MobileFrontend and GoogleLogin, will rewrite the handler for the Login class.
GoogleLogin will do this only, if $wgGLReplaceMWLogin is set to true to prevent
the vanilla LoginForm to appear.

MobileFrontend was created in an early version of MediaWiki and had to replace
the LoginForm, too, to fit the needs of a mobile device (it will do this every
time, the user is in mobile mode).

Now, the problem is, that the login page can be only one class and it wins the
extension that has overwritten the key last.

So, in fact, the Extension which was loaded last will provide the login screen.
That means for you, as a quick fix, that you can place the "require_once" line
of GoogleLogin somewhere _after_ the MobileFrontend "require_once" line. This
should solve the problem for now.

The best solution is, that MobileFrontend doesn't need to overwrite the login
page anymore. Actually, the developer team is working on this and implemented
such a feature in the alpha mode of MobileFrontend
(I8f89bdaf3dc7fde104f199554b18486c30580910). It will take some time to solve
this problem, but it isn't a real bug of GoogleLogin. I will create a tracking
but for this in MobileFrontend :)

(I will set the status of this bug to assigned and take it anyway, but the work
has to be done in MobileFrontend :))

P.S.: Thanks for the very detailed bug report! :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to