Closed Bug 1278992 Opened 4 years ago Closed 4 years ago

Always show the URL bar dropmarker when in customization mode

Categories

(Firefox :: Theme, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 50
Tracking Status
firefox50 --- verified

People

(Reporter: jaws, Assigned: Towkir, Mentored)

References

Details

(Whiteboard: [good first bug][lang=css])

Attachments

(1 file, 1 obsolete file)

The URL bar dropmarker, which is the down arrow at the end of the location bar, only shows when hovering the location bar.

But in customization mode the location bar is disabled and can't be interacted with. We should always show the dropdown bar in this view, since it does consume space and will affect how much of the URL will be visible when not in customization mode.

The CSS code for this is in browser/themes/windows/browser.css, browser/themes/linux/browser.css, and browser/themes/osx/browser.css.

Look for:
#navigator-toolbox:not(:hover) #urlbar:not([focused]) > .urlbar-textbox-container > .urlbar-history-dropmarker

This rule should be changed to not apply if the #urlbar is disabled.
Summary: Show the URL bar dropmarker all the time when in customization mode → Always show the URL bar dropmarker when in customization mode
Hello Jared,

I'm interested in working on this bug. I have already resolved a couple of bugs related to Mozilla. 
Hoping to work on this bug.

Thank You.
Great, let me know how I can help you. I usually wait until you attach a patch for me to mark the bug as assigned.
Sure Jared. I'll submit a patch and will report the progress soon!
Hello Jared,

Since a day I'm trying to build firefox on my Ubuntu 15.10 but I'm getting error. Following the build instructions, when I run the command 'wget -O bootstrap.py https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py && python bootstrap.py', I gives error at the end. I googled it to find this bug which is causing the error (https://bugzilla.mozilla.org/show_bug.cgi?id=1174037). But it doesn't clearly mention how to resolve it and build firefox.

I feel glad if you can help me out with this issue.

Thank You.

Output of the command 'wget ...' : http://pastebin.com/z30GC0BJ
bootstrap.py generated : http://pastebin.com/FYDkpa5r
Sorry..Output of the command 'wget ... ' : http://pastebin.com/jHLuS8cZ
You want the dropmaker to be visible always only in customize mode ? I can submit a patch, but I have a confusion, if the urlbar is disabled in customized mode, I have seen the dropmaker only appears while hovering, but does nothing on clicking. why are we showing this plz ?
(In reply to [:Towkir] Ahmed from comment #6)
> You want the dropmaker to be visible always only in customize mode ? I can
> submit a patch, but I have a confusion, if the urlbar is disabled in
> customized mode, I have seen the dropmaker only appears while hovering, but
> does nothing on clicking. why are we showing this plz ?

From comment #0,

"We should always show the dropdown bar in this view, since it does consume space and will affect how much of the URL will be visible when not in customization mode."
Ok I get it, I will submit a patch soon. and will contact you if I need help. Thanks
Assignee: nobody → 3ugzilla
I tried every possible way to set this rule not to apply when the urlbar is disabled. Looks like the urlbar is not disabled while the browser enters customization mode. is it possible that the urlbar is not disabled but in some other way it is made inactive ?? or what happens to the urlbar while browser enters customization mode ??
I tried :

#navigator-toolbox:not(:hover) #urlbar:not([focused]):not([disabled]) > .urlbar-textbox-container > .urlbar-history-dropmarker

#navigator-toolbox:not(:hover) #urlbar:not([focused]) > .urlbar-textbox-container:not([disabled]) > .urlbar-history-dropmarker

#navigator-toolbox:not(:hover) #urlbar:not([focused]) > .urlbar-textbox-container > .urlbar-history-dropmarker:not([disabled])

and so on. but they don't seem to work
Flags: needinfo?(jaws)
Try this instead,

#navigator-toolbox:not(:hover) #navbar:not([customizing="true"]) #urlbar:not([focused]) > .urlbar-textbox-container > .urlbar-history-dropmarker

Instead of focusing on whether it is disabled, we should just single out customization mode.
Flags: needinfo?(jaws)
OK, great.
I was also thinking the same.

#navigator-toolbox:not(:hover) #nav-bar:not([customizing="true"]) #urlbar:not([focused]) > .urlbar-textbox-container > .urlbar-history-dropmarker {
  opacity: 0;
}

has done it perfect. shall I set the r=jaws ?
You should create a patch with those changes and attach it to the bug. I will then review it and set r=jaws myself if it looks right.
Attached patch urlbarhistorydropmaker.patch (obsolete) — Splinter Review
I had generated a patch after a long hassle with fsmonitor/watchman etc.
I hope it looks good. Now what ? Shall I commit and push ?
will take next step after your comment on this.
Thanks
Attachment #8763772 - Flags: review?(jaws)
Comment on attachment 8763772 [details] [diff] [review]
urlbarhistorydropmaker.patch

Review of attachment 8763772 [details] [diff] [review]:
-----------------------------------------------------------------

Please update your commit message. It should not include the filename that is modified as that is already defined by the patch itself. It is better if the commit message says *why* the change is happening.

Comment in the bug with what you think the commit message should be and I'll let you know if I approve. After we get a good commit message then we can land this.
Attachment #8763772 - Flags: review?(jaws) → review+
I think the commit message should be this:
Bug 1278992 made the urlbar history dropmaker always visible while in customize mode

Shall I modify it and attach another patch ?
Let's go with:

Bug 1278992 - Show the URL bar history dropmarker in customize mode to help users simulate the browser outside of customize mode. r=jaws

After you update the commit message, upload the patch to this bug with that commit message and then I will mark it as checkin-needed. Once it's marked, it should get checked in within 24 hours and will appear in the next Nightly build within 48 hours.
Status: NEW → ASSIGNED
Here is the patch with updated commit message.
Attachment #8763772 - Attachment is obsolete: true
Okay, this limits the hiding of the dropmarker to only happen when the urlbar is in the navbar, but since we don't allow it to move outside of the navbar natively this should be fine. Users can only  move the urlbar out of the navbar by using a 3rd-party add-on.
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/fx-team/rev/54b7ab33783d
Show the URL bar history dropmarker in customize mode to help users simulate the browser outside of customize mode. r=jaws
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/54b7ab33783d
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
Assignee: 3ugzilla → nobody
QA Whiteboard: [good first verify]
sorry that I removed myself from the assignee field accidentally
Assignee: nobody → 3ugzilla
I have reproduced on Firefox nightly according to(2016-06-08)

It's fixed and verified on Developer Edition--Build ID:( 20160630004007 ), User Agent: 	Mozilla/5.0 (Windows NT 10.0; rv:49.0) Gecko/20100101 Firefox/49.0

Tested OS-- Windows10 32bit
QA Whiteboard: [good first verify] → [bugday-20160629]
It's also fixed and verified on Latest Nightly.

Build ID    : 20160630030207
User Agent  : Mozilla/5.0 (Windows NT 10.0; rv:50.0) Gecko/20100101 Firefox/50.0

(In reply to Saheda Reza [:Antora] from comment #22)
I have reproduced this bug on Nightly 50.0a1 (2016-07-26) (Build ID: 20160726080520) on Linux, 64 bit!

The bug's fix is now verified on Latest Nightly 50.0a1!

Build ID: 20160726080520
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
OS: Ubuntu 16.04, Linux 4.4.0-31-generic

As this bug's fix is also verified on Windows 10 32bit (comment 22), I am marking this as verified!
Status: RESOLVED → VERIFIED
QA Whiteboard: [bugday-20160629] → [bugday-20160629][bugday-20160727]
You need to log in before you can comment on or make changes to this bug.