Closed
Bug 941176
Opened 12 years ago
Closed 11 years ago
[User Story] [Meta] Browser Chrome: View title
Categories
(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)
Tracking
(feature-b2g:2.1)
People
(Reporter: pdol, Assigned: vingtetun)
References
Details
(Keywords: verifyme, Whiteboard: [ucid:System126, 1.4:P2, ft:systemsfe], system-browser, [p=2])
Attachments
(1 file)
User Story:
As a user I want to view the title of the web page I'm currently on so that I can see the title of the website I am currently viewing.
Acceptance Criteria:
Functionality should match existing Browser functionality unless described otherwise in UX spec.
Reporter | ||
Updated•12 years ago
|
Blocks: browser-chrome-mvp
Updated•12 years ago
|
Component: Gaia::System → Gaia::System::Browser
Updated•12 years ago
|
No longer blocks: browser-chrome-mvp
Reporter | ||
Updated•12 years ago
|
Blocks: browser-chrome-mvp
Updated•12 years ago
|
Comment 1•12 years ago
|
||
Dale - just marking you as reviewer so you are aware. We should probably land your places datastore work first, or this will cause conflicts - and I'm sure I've given you plenty of those already :)
Feel free to review now, and we can land it at a later date. Tests are coming.
Attachment #8350674 -
Flags: review?(dale)
Comment 2•12 years ago
|
||
Comment on attachment 8350674 [details] [review]
Github pull request
Starting to touch some system components, so alive should probably review this one as well :)
Attachment #8350674 -
Flags: review?(alive)
Comment 3•12 years ago
|
||
Comment on attachment 8350674 [details] [review]
Github pull request
I'd like to publish the events from appWindow instead of appChrome.
To do this you need to add new events in AppWindow.REGISTERED_EVENTS and implement _handle_ + EVENT_NAME handler in AppWindow.prototype.
AppWindow.prototype.publish is your good friend to publish events.
Apology for not documenting these principles well.
Attachment #8350674 -
Flags: review?(alive)
Comment 4•12 years ago
|
||
Comment on attachment 8350674 [details] [review]
Github pull request
Hi Alive,
Thanks for the awesome/quick review. I added one commit for some tests, and one commit for some adjustments. (Will squash before landing).
The new adjustments make sense and feel clean to me, so great ideas! Please let me know if you find anything else.
Attachment #8350674 -
Flags: review?(alive)
Comment 5•12 years ago
|
||
Comment on attachment 8350674 [details] [review]
Github pull request
Gonna clear r, theres a bug where navigating from web content to app contant (in particular e.me results) the title of the web content persists, I think its a pretty big bug that should be simple to fix, so think it would be good to fix before merging
It also looks strange on the lockscreen, however I think thats a more complex fix that will require UI follow up, so happy to merge before fixing that.
The rest looks really great, the tests on travis look unrelated so spun a new run
Attachment #8350674 -
Flags: review?(dale)
Comment 6•12 years ago
|
||
Comment on attachment 8350674 [details] [review]
Github pull request
Hi Dale,
I've pushed a fix (including test), which does not allow inactive app windows to update the title. Before, the titlechange may have been updating the title after you close the window. I think this may have been what you are seeing.
To clarify, the following cases work for me:
1 - Open rocketbar, type url, press enter. Title appears.
2 - Press home, launch app
3 - Title disappears
1 - Open rocketbar, type url, press enter. Title appears.
2 - Open rocketbar again, and tap everything.me result
3 - Title updates with new E.me page title.
Attachment #8350674 -
Flags: review?(dale)
Comment 7•12 years ago
|
||
Comment on attachment 8350674 [details] [review]
Github pull request
Yup thats great, apologies for not being clearer with the STR
New version looking awesome
Attachment #8350674 -
Flags: review?(dale) → review+
Comment 8•12 years ago
|
||
Comment on attachment 8350674 [details] [review]
Github pull request
Alive - I've updated the pull request based on your feedback, and if you have any additional concerns, we can submit follow-up patches.
Attachment #8350674 -
Flags: review?(alive)
Comment 9•12 years ago
|
||
Landed in master: https://github.com/mozilla-b2g/gaia/commit/56958810b8c51a513b6ef3263a362da7c9922d7f
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 10•12 years ago
|
||
This is a good start but let's keep the user story open until we're ready for acceptance from Product/QA, we're not quite done here yet as it doesn't meet the UX spec.
Stealing.
Assignee: kgrandon → bfrancis
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•12 years ago
|
Target Milestone: --- → 1.3 C2/1.4 S2(17jan)
Comment 11•12 years ago
|
||
Let's make this a meta bug.
Assignee: bfrancis → nobody
Summary: [User Story] Browser Chrome: View title → [User Story] [Meta] Browser Chrome: View title
Comment 12•12 years ago
|
||
I don't see a lot here, and I *think* that most work is now going to be a part of bug 959694. Closing so our focus for user testing makes sense.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Comment 13•12 years ago
|
||
We're still not done here. Please leave this bug open until we're ready for acceptance by Product/UX/QA.
Unblocking 959353 as the patch on the Rocketbar branch fixes that requirement.
Comment 14•12 years ago
|
||
Estimating as 2 points. This is assuming the necessary platform pieces are in place. We need some limited logic here to decide when to display the content of the <title> element, the app name, or the application-name meta tag.
Whiteboard: [ucid:System126, 1.4:P2, ft:systems-fe], system-browser → [ucid:System126, 1.4:P2, ft:systems-fe], system-browser, [p=2]
Updated•12 years ago
|
No longer blocks: rocketbar-search-mvp
Updated•12 years ago
|
Blocks: 1.4-systems-fe
Flags: in-moztrap?(nhirata.bugzilla)
Updated•11 years ago
|
No longer blocks: 1.4-systems-fe
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → backlog
feature-b2g: --- → 2.1
Updated•11 years ago
|
Whiteboard: [ucid:System126, 1.4:P2, ft:systems-fe], system-browser, [p=2] → [ucid:System126, 1.4:P2, ft:systemsfe], system-browser, [p=2]
Comment 15•11 years ago
|
||
Candice, can you help to assign updated target milestone for this 2.1 bug? Thanks.
Flags: needinfo?(cserran)
Updated•11 years ago
|
Assignee: nobody → bfrancis
blocking-b2g: backlog → ---
Flags: needinfo?(cserran)
Target Milestone: 1.3 C2/1.4 S2(17jan) → 2.1 S1 (1aug)
Comment 16•11 years ago
|
||
Looks like Vivien is working on this in bug 1039519, not much point in it being assigned to me.
https://bugzilla.mozilla.org/show_bug.cgi?id=1039519#c22
Assignee: bfrancis → 21
Updated•11 years ago
|
Target Milestone: 2.1 S1 (1aug) → 2.1 S2 (15aug)
Updated•11 years ago
|
Target Milestone: 2.1 S2 (15aug) → 2.1 S3 (29aug)
Comment 17•11 years ago
|
||
Ready for acceptance testing :)
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Keywords: verifyme
Resolution: --- → FIXED
Updated•11 years ago
|
Flags: in-moztrap?(nhirata.bugzilla) → in-moztrap?(mozillamarcia.knous)
Updated•10 years ago
|
Flags: in-moztrap?(mozillamarcia.knous)
You need to log in
before you can comment on or make changes to this bug.
Description
•