Page loads do not respect visibility of Awesome Bar Results

VERIFIED FIXED in fennec1.0b4

Status

Firefox for Android Graveyard
General
--
major
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: aakashd, Assigned: vingtetun)

Tracking

Trunk
fennec1.0b4
Bug Flags:
wanted-fennec1.0 ?
in-litmus +

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

9 years ago
Build Ids:

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.3a1pre) Gecko/20090826 Fennec/1.0a3pre

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a1pre) Gecko/20090827
Fennec/1.0b4pre


Steps to Reproduce:
1. Start a page load ( try pages with heavy content to see this more easily like www.espn.com )
2. Click on the URL bar during page load to open up the awesome bar results
3. Type a search entry into the field while the page is loading
4. Wait until the page has finished loading

Actual Results:
The awesome bar results will be gone, the loaded page will show and the url bar will be include the search entry

Expected Results:
The awesome bar results should still be shown on top of the loaded page
Flags: wanted-fennec1.0?
(Reporter)

Updated

9 years ago
tracking-fennec: --- → ?
I think this is related to places performance.  Very noticeable on WinMo builds.
Created attachment 400282 [details] [diff] [review]
Patch

It's more related to us :)
Attachment #400282 - Flags: review?(mark.finkle)

Updated

9 years ago
tracking-fennec: ? → 1.0+
Assignee: nobody → 21
Attachment #400282 - Flags: review?(mark.finkle) → review+
pushed:
https://hg.mozilla.org/mobile-browser/rev/4e916c8dfe5d
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → B4
(Reporter)

Comment 4

9 years ago
verified FIXED on builds:

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.2a2pre) Gecko/20090916 Fennec/1.0a3

and

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.3a1pre) Gecko/20090916
Fennec/1.0a3

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.2a2pre) Gecko/20090916
Fennec/1.0b4pre
Status: RESOLVED → VERIFIED
This patch broke search buttons (bug 517030)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Created attachment 401215 [details] [diff] [review]
Patch v0.2

A new package full of regressions! - feel free to r- :)
Attachment #401215 - Flags: review?(mark.finkle)
Comment on attachment 401215 [details] [diff] [review]
Patch v0.2


> 
>+  setToolbarValue: function(aValue) {
>+    if (this.isToolbarOpen())
>+      this._edit.defaultValue = aValue;
>+    else
>+      this._edit.value = aValue;
>+  },

Rename setToolbarValue to _setURI(aCaption)and move it to above _editToolbar.

Also, rename _editToolbar to __editURI and setURI to updateURI

>+  isToolbarOpen: function isToolbarOpen() {
>+    return this._edit.popup.popupOpen;
>+  },

Rename this to isAutoCompleteOpen() and move it above showAutoComplete()

>   doButtonSearch : function(button) {

>-    var urlbar = this._edit;
>-    urlbar.open = false;
>-    var value = urlbar.value;
>+    // We don't want the button to look pressed for now
>+    button.parentNode.selectedItem = null;

Actually, we _do_ want to see the button press, so remove those lines

>+    
>+    let urlbar = this._edit;
>+    urlbar.reallyClosePopup();

Drop the "urlbar" variable and just use "this._edit"


I want the renaming so we better understand what these methods _do_ from their names. The _editToolbar, for example has been around a long time and has changed it's implementation enough that the name no longer fits.
Attachment #401215 - Flags: review?(mark.finkle) → review-
Created attachment 401433 [details] [diff] [review]
Patch v0.3

So finally this patch add:
 * prevent the awesome bar to close unexpectedly
 * open the urlbar = focus / close the awesome bar = blur
 * keep the search string while the awesomebar is open
 * prevent the search buttons to look pressed
by the way this also resolved bug 515988.

The patch should be regression free...
Attachment #400282 - Attachment is obsolete: true
Attachment #401215 - Attachment is obsolete: true
I didn't find any regression

pushed:
https://hg.mozilla.org/mobile-browser/rev/5c026a0bdffa
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
on the 20099021 1.9.2 nightly build, this retains the awesome bar state, but I cannot continue to type in the url bar, and selecting an awesomebar result seems to have a really long lag.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
That's just a lag :)
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
yeah, Verified on n810 with 1.9.2 nightly build 20090921
Status: RESOLVED → VERIFIED
(Reporter)

Updated

9 years ago
Flags: in-litmus?
in+litmus+

https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=9767
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.