552832 - Make about: pages in Fennec be local, in-content UI

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Doug Turner (:dougt)]

This is because our about:fennec file uses chrome content.

Comment 1

[chithraprabha]

My understanding about this issues is, the URL for loading this page , which  chrome file URL 'chrome://browser/content/about.xhtml' is available  from the component defined in mobile/components/AboutRedirector.js file, which seems to be not accessible from content process or nsAboutProtocolHandler.

Some stack trace here :- 
Breakpoint 3, nsIOService::NewChannelFromURI (this=0xb7d07700, aURI=0xb2d57640, result=0xbfffc96c)
    at /home/chithra/E10s-GTK-May27/electrolysis/netwerk/base/src/nsIOService.cpp:604
604	    NS_ENSURE_SUCCESS(rv, rv);
(gdb) bt
#0  nsIOService::NewChannelFromURI (this=0xb7d07700, aURI=0xb2d57640, result=0xbfffc96c) at /home/chithra/E10s-GTK-May27/electrolysis/netwerk/base/src/nsIOService.cpp:604
#1  0x0205b528 in nsChromeProtocolHandler::NewChannel (this=0xb4438e60, aURI=0xb2d57100, aResult=0xbfffcbc4)
    at /home/chithra/E10s-GTK-May27/electrolysis/chrome/src/nsChromeProtocolHandler.cpp:205
#2  0x0118a895 in nsIOService::NewChannelFromURI (this=0xb7d07700, aURI=0xb2d57100, result=0xbfffcbc4)
    at /home/chithra/E10s-GTK-May27/electrolysis/netwerk/base/src/nsIOService.cpp:603
#3  0x01181e76 in NS_NewChannel (result=0xbfffcd08, uri=0xb2d57100, ioService=0xb7d07700, loadGroup=0x0, callbacks=0xb4871fa8, loadFlags=524288, channelPolicy=0x0)
    at ../../../dist/include/nsNetUtil.h:219
#4  0x01f7e0c6 in nsDocShell::DoURILoad (this=0xb4871f90, aURI=0xb2d57100, aReferrerURI=0x0, aSendReferrer=1, aOwner=0x0, aTypeHint=0x0, aPostData=0x0, aHeadersData=0x0, 
    aFirstParty=1, aDocShell=0x0, aRequest=0xbfffce5c, aIsNewWindowTarget=1, aBypassClassifier=0, aForceAllowCookies=0)
    at /home/chithra/E10s-GTK-May27/electrolysis/docshell/base/nsDocShell.cpp:8346


In ***********nsAboutProtocolHandler::NewChannel' ( uriloader/exthandler/nsAboutProtocolHandler.cpp:395 ) -- > nsresult rv = NS_GetAboutModule(uri, getter_AddRefs(aboutMod)); *************
fails to get the handler (failed when *****CallGetService(contractID.get(), aModule); ********* )to get the URL from component in js file from mobile code. 


I guess not only 'About Fennec' page ,but  other pages  like  'About Firstrun', 'About Rights', 'About Certificate Error', 'About Firefox', 'About Home'  pages , are also busted due to the same reason.


Do we need some new  IPC code to get the 'about protocol' working for these pages ? I would be nice if some one can suggest what is missing for fixing this issue.

Comment 2

[Doug Turner (:dougt)]

serialization of urls are currently broken.  are you testing with my e10s patch queue?

Comment 3

[chithraprabha]

Nope, I missed the patches I hope you mean the patches from 'http://hg.mozilla.org/users/dougt_mozilla.com/e10s-patches, will try with the patches. Thanks.

Comment 4

[chithraprabha]

This bug is reproducible with the patches from e10s patch queue also.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

This bug will be handled in Fennec front-end code as such:

* Any about: page will always be opened in a new tab
* The new tab will be <browser remote="false"> (non-e10s) so it will work just like it does now
* The new tab will not have a writable URLBar so it can't be reused for normal web pages, and therefore will not need a ipc/non-ipc session history.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #5)

> * The new tab will not have a writable URLBar so it can't be reused for normal
> web pages, and therefore will not need a ipc/non-ipc session history.

We decide to keep a writable URLbar for now.

* Opening an about: page _always_ opens a new tab
* Opening a new webpage from an about: page will open the web page in a new tab.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: patch

This patch implements the behavior described above

Comment 8

[Matt Brubeck (:mbrubeck)]

Comment on attachment 451749 [details] [diff] [review]
patch

The one place where this is noticeable in normal use is that the start page (about:home or about:firstrun) will always remain open in the first tab until the user closes it manually.  I think we'll want to fix that somehow, but I'd be fine with doing that in a followup bug if you prefer.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #8)
> (From update of attachment 451749 [details] [diff] [review])
> The one place where this is noticeable in normal use is that the start page
> (about:home or about:firstrun) will always remain open in the first tab until
> the user closes it manually.  I think we'll want to fix that somehow, but I'd
> be fine with doing that in a followup bug if you prefer.

Yeah, I was torn over this behavior, but thought it might be nice to keep the Start Page around instead of destroying it. We'll find out as we use it a bit.

I do plan to file a followup bug to tweak the behavior and, possibly, the UI. I started to think about making "app tabs" and adding support for Apple's "no URLbar" tabs for web apps.

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 451749 [details] [diff] [review]
patch

>diff --git a/chrome/content/browser-ui.js b/chrome/content/browser-ui.js
>     browser.setAttribute("style", "overflow: -moz-hidden-unscrollable; visibility: hidden;");
>     browser.setAttribute("type", "content");
> 
>     let useRemote = gPrefService.getBoolPref("browser.tabs.remote");
>-    browser.setAttribute("remote", useRemote ? "true" : "false");
>-
>+    let useLocal = aURI.indexOf("about") == 0 && aURI != "about:blank";
>+    browser.setAttribute("remote", (!useLocal && useRemote) ? "true" : "false");
>+    

useLocal == isLocalURI?

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed to m-b:
http://hg.mozilla.org/mobile-browser/rev/e68f77b005f3

I left useLocal alone for now. It matched useRemote


Just to summarize. Here is the current behavior:
* about: pages should always open in a new, local tab
* if the current page is a local about: page, a web page (typed in url or awesomebar) will open in a new tab
* if current page is a web page, a web page (typed in url or awesomebar) will open in a current tab
* web pages will use local or remote tabs based on the "browser.tabs.remote" preference.

Comment 12

[Aakash Desai [:aakashd]]

verified FIXED on build:

Mozilla/5.0 (X11; U; Linux armv71; Nokia N900; en-US; rv:1.9.3a6pre) Gecko/2010621 Namoroka/3.7a6pre Fennec/2.0a1pre



Follow-up bugs filed: 573567, 573566, 573571

Comment 13

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Litmus Test Cases created:

https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=12941

(still need to write a couple of more to cover the other conditions)

Comment 14

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=12959
https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=12960
https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=12961