Closed Bug 848660 Opened 12 years ago Closed 12 years ago

Gaia value selector does not work anymore

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
All
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking-b2g:leo+, firefox20 wontfix, firefox21 wontfix, firefox22 fixed, b2g18 fixed, b2g18-v1.0.0 unaffected, b2g18-v1.0.1 unaffected)

Status:
RESOLVED FIXED
Milestone:
B2G C4 (2jan on)
Project Flags:
blocking-b2g leo+
Tracking Flags:
Tracking Status
firefox20 --- wontfix
firefox21 --- wontfix
firefox22 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- unaffected
b2g18-v1.0.1 --- unaffected

People

(Reporter: kanru, Assigned: xyuan)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

patch ready to checkin
(deleted), patch
fabrice
: review+
Details | Diff | Splinter Review 
STR:

1. Open Settings -> Display
2. Selecet "Screen timeout"

Expected:

A menu appears for selecting

Actual:

Nothing happened. A JavaScript error "encoder is null" in adb logcat output.

Looks like its bug 818893 regressed it.
I'm taking a look at the bug.
Assignee: nobody → xyuan
It happens in multiple places not just FTU, settings, but in calendar, email, etc. where most places have drop downs.
Severity: normal → critical
Keywords: regression
blocking-b2g: --- → leo?
A regression window would be helpful here.

Also - Does this reproduce on a v1.0.1 build?
Keywords: regressionwindow-wanted
Please ensure there's an automated unit test checked in with this fix, so that it cannot happen again.
(In reply to Dietrich Ayala (:dietrich) from comment #8)
> Please ensure there's an automated unit test checked in with this fix, so
> that it cannot happen again.

FWIW, bug 848988 (a dupe of this) indicates we've got a Gaia UI Test covering this. Which did end up catching this bug, btw.
Attached patch Fix gaia selector (obsolete) (deleted) — — Splinter Review 
The bug was caused by the getSelectionRange function in b2g/chrome/forms.js, which treated the selector as content editable element improperly and failed to get its selected text range. 

For the selector, there is no selected text and we don't need the selected text range info either.

Threrefor, to solve this issue, we only needs to prevent the getSelectionRange function from getting the selected text range of the selector.  That's what the patch has done.
Attachment #722620 - Flags: review?(dflanagan)
Comment on attachment 722620 [details] [diff] [review]
Fix gaia selector

Look for someone to review this urgent patch as I don't know if David has time. :-(

The change is small and of low risk, so if you have time, please feel free to help.
Attachment #722620 - Attachment is patch: true
Sounds like we've already got a patch here, so a regression window no longer appears necessary.
Keywords: regressionwindow-wanted
Attachment #722620 - Flags: review?(dflanagan) → review+
is bug 848922 related?
(In reply to Naoki Hirata :nhirata from comment #14)
> is bug 848922 related?

That actually looks different - that's talking about opening a link to the browser. This talks about the select dialog box not working.
I am also seeing that it is now impossible to click on a thumbnail in the gallery when the gallery has been opened for selection. I assume this is related as the problem started at the same time.

STR:

1. Edit a contact
2. Click the "Add Picture" button.
3. Choose "Gallery" as the source.
4. Click a thumbnail in the Gallery.

Expected result: The picture is opened for cropping.
Actual result: Nothing happens (at step 4).
Thank Fabrice for the reviewing and I would like to check-in it.
Keywords: checkin-needed
(In reply to Bob Silverberg from comment #16)
> I am also seeing that it is now impossible to click on a thumbnail in the
> gallery when the gallery has been opened for selection. I assume this is
> related as the problem started at the same time.
> 
> STR:
> 
> 1. Edit a contact
> 2. Click the "Add Picture" button.
> 3. Choose "Gallery" as the source.
> 4. Click a thumbnail in the Gallery.
> 
> Expected result: The picture is opened for cropping.
> Actual result: Nothing happens (at step 4).

You might be talking about bug 849290 potentially.
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/94927529a55f
Gaia   87801b12cd3aac153fae84844da8f1e6455ea679
BuildID 20130308070202
Version 18.0

Tested in a Unagi device, was able to reproduce this bug - Drop downs are not functioning in date/time, display->screen timeout, calendar, etc.
That does sound like my issue, Jason, although I wouldn't be surprise if that is a symptom of this same bug. I'm not sure how to best track that, but I guess with both bugs open it will be addressed.

(In reply to Jason Smith [:jsmith] from comment #18)
> 
> You might be talking about bug 849290 potentially.
(In reply to Bob Silverberg from comment #20)
> That does sound like my issue, Jason, although I wouldn't be surprise if
> that is a symptom of this same bug. I'm not sure how to best track that, but
> I guess with both bugs open it will be addressed.
> 
> (In reply to Jason Smith [:jsmith] from comment #18)
> > 
> > You might be talking about bug 849290 potentially.

If this bug fixes that other bug, we can just close the other bug when we confirm this bug fixes that issue.
(In reply to Yuan Xulei [:yxl] from comment #17)
> Thank Fabrice for the reviewing and I would like to check-in it.

This is a critical regression - why are we further delaying getting this in??
blocking-b2g: leo? → leo+
We are sure this doesn't affect v1.0.1, right?
Attached patch patch ready to checkin (deleted) — — Splinter Review 
inbound is closed, so I can't push now...
Attachment #722620 - Attachment is obsolete: true
Attachment #723026 - Flags: review+
(In reply to Jason Smith [:jsmith] from comment #23)
> We are sure this doesn't affect v1.0.1, right?

Yes, we are.
blocking-b2g: leo+ → leo?
status-b2g18-v1.0.0: unaffected → ---
status-b2g18-v1.0.1: unaffected → ---
(In reply to Yuan Xulei [:yxl] from comment #25)
> (In reply to Jason Smith [:jsmith] from comment #23)
> > We are sure this doesn't affect v1.0.1, right?
> 
> Yes, we are.

@Alex, I'm sorry that the cache of my browser changed the tracking flags back. I can reset the status-b2g18-v1.0.0 and status-b2g18-v1.0.1 flag, but don't have permission to reset blocking-b2g flag.

As Fabrice mentioned, the inbound is closed, and then when or how can we push this fix?
status-b2g18-v1.0.0: --- → unaffected
status-b2g18-v1.0.1: --- → unaffected
https://hg.mozilla.org/mozilla-central/rev/be905015b253
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
How soon can this get uplifted so that it is not seen during smoketesting? It is still affecting the builds we are testing today and affects build promotability:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/aec2f0738fab
Gaia   067c040f3f16d5660ab1e117abf0834f1509d6f3
BuildID 20130311070203
Version 18.0
blocking-b2g: leo? → leo+
(In reply to Yuan Xulei [:yxl] from comment #26)
> (In reply to Yuan Xulei [:yxl] from comment #25)
> > (In reply to Jason Smith [:jsmith] from comment #23)
> > > We are sure this doesn't affect v1.0.1, right?
> > 
> > Yes, we are.
> 
> @Alex, I'm sorry that the cache of my browser changed the tracking flags
> back. I can reset the status-b2g18-v1.0.0 and status-b2g18-v1.0.1 flag, but
> don't have permission to reset blocking-b2g flag.

Fixed.
https://hg.mozilla.org/releases/mozilla-b2g18/rev/a56593f84577
status-b2g18: affected → fixed
status-firefox20: --- → wontfix
status-firefox21: --- → wontfix
Target Milestone: --- → B2G C4 (2jan on)
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap+
Added Settings Suite Test Case #8597 - [Settings] Verify the drop down value selectors work without error
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: